如何解决有限的资源和运算能力分配问题

这个问题实际就是我们经常讨论的软件可伸缩性Scalable或可扩展性问题。

第一步：应用服务器和数据库服务器的资源和计算能力没有均衡分布，你这个案例是几乎负载都集中到数据库上了，而应用服务器闲置，解决这个一现象可以通过在应用服务器中引入缓存的方式。

第二步：如果应用服务器的缓存丢失率高，说明应用服务器和数据库服务器负载都很高，那么我们可以在应用服务器和数据库服务器之间引入分布式缓存如memcached。

现在架构是：
client -- > 应用服务器 (in-memory Cache) ---> memcached ---->DB

下一步就是引入云计算技术：
云计算有两种方式：一种是自己引入云计算组件，做私有云：比如对于一些复杂计算耗费CPU且频繁调用的报表计算，比如数据仓库挖掘等可以使用云计算Hadoop；对于爆炸增长的大数据量引入NoSQL等等。

另外一种是租用现有的云计算平台，租用公有云，比如Google和Amazon。

帮主，您好，首先对您的回复表示感谢。您讲得可伸缩和扩展性问题，这方面的理论，我目前尚且略知一二。不过我认为您的答复并没有正面回答我所关心的核心问题，那就是部署在服务器上运行中的应用们是如何相互争夺资源的？有点类似多线程的调度（要么虚拟机管理调度，要么操作系统负责），可是应用们获取运行时所需资源的多与少，这个地方的调度管理究竟是由谁，什么规则来调度呢？希望大家多多讨论，谢谢

首先：编程时尽量避免多线程的资源争夺，多线程有一个致命问题是资源争夺，那么难免使用锁，这些都是导致资源利用率下降的根本原因，因此，在目前多线程编程中，尽量使用不变性，或者直接使用缺省是不变性的语言Scala。这些都能避免资源纠结与争夺。

其次：无论微观如何争夺调度，我们也需要在宏观整体进行调度。在程序中多引入异步，异步可能到来最终一致性，这些都需要根据情况选用，尽量避免或缩小事务或数据库锁JDBC等锁定资源的使用范围。

这里有一个消耗资源大小或耗费性能的排列：
基于内存异步事件 ---> 内存锁 --->事务锁 --->数据库锁。
越是后面，性能越差，可伸缩性越差，资源利用帅越差，闲置率越高。

这里比较一下异步和通常同步，也就是你们现在架构的区别：
同步情况下：当你发出请求必然有一个响应结果，但是你可能接着还需要继续其他更多处理，不是立即用到这个响应结果。
这样，你不必发出请求后，就在那里傻等响应结果，而是继续做你其他更多处理，直到需要它时才过来取。
生活中排队，你去买两样东西，一样东西需要排队，那么先买不需排队的，再过来买。

等待时线程会闲置，会消耗系统资源。对于一个高交互量的系统，线程闲置数= arrival_rate * processing_time。如果arrival_rate很高，闲置数将非常高，系统工作在一个非常无效率的状态。

我上面的一个帖子是提出了解决办法，这个帖子是解释了原因，希望能够帮助到你。

在自己测试环境自己的软件是正常的，而到生产现场则不正常，这个现象非常普遍，主要是我们以前只考虑功能，没有过多考虑运营复杂状况，还有测试部门对生产现场的数据采样没有跟上，能够尽量模拟生产现场，其实最终结的办法是Event Sourcing，使用一个NoSQL将所有用户操作事件日志保留下来，然后在调试环节回放。

只有采集数据接近现实，你就能通过调试判断：应用以目前的水平，在拥有多少资源和运算能力下，可以很稳定地运行。

如果你觉得这样的数据难以获取，那么就采取可扩展的云架构，通过虚拟化技术和自动伸缩扩展功能，随着你的资源和运算能力多少，自动调配资源。
[该贴被banq于2011-12-23 09:19修改过]

对于第1个问题，可以通过监控服务器 硬盘、CPU等情况确定服务器是否满负荷了？对于第2个问题，可以通过监控数据库运行的SQL语句，SQL语言运行的效率，服务器运行的效率来判别是否数据库满负荷。

如果是以上2个问题导致的，那么就只能增加服务器解决或者移走其它应用。

但是，在验证上面2个问题之前，你是否确认你得产品在生产环境下是正常的。是否跟踪过你的产品处理过程每个环节，是否有调试每个环境处理的时间，性能等情况？

在此稍微说点题外话，其实，大家在遇到问题的时候，我感觉往往过于着急得到答案，其实这完全是不符合真正意义编程的风格的，问题的提出源自深入的思考，问题的解决绝对百分之九十九是分析，分析透了，解决自然不成问题。点到为止，我不想做一个大嗓门扯“大道理”的人，我还是鼓起勇气重拾C吧，不了解底层的程序员得真实地面对自己的提升瓶颈了，我给自己列好了一个长长的书目，你呢？大家多努力吧，谢谢。

[该贴被BinnyJ于2011-12-25 20:09修改过]

我觉得大家是不是都没明白楼主的意思呢?
楼主想要的应该是:"想知道操作系统是如何对资源进行分配,它为什么要这么分配,运算能力又是如何分配的,分配的规则是什么?"
而不是问大家这些问题要如何解决.

ronalfei同学说得对。这就是我关心的核心问题，大家多多讨论，我不着急，有什么新的想法，我也会及时发帖子说明的，谢谢大家

我不反对探究底层机制，Disruptor也是因为LMAX团队研究到CPU的缓存后才发现64字节特性。据我所知，不同的操作系统和硬件，支持不同的策略的资源分配和运算，比如Java中常讲的CAS一般需要底层操作系统支持，可在这方面研究，推荐这个帖子：The Art of Multiprocessor Programming多线程编程艺术。

不过因为操作系统对资源的调配就是我们了解了，很多时候我们无法干预控制，操作系统提供那么多的多线程可能难以编写使用，所以，业界就产生了另外两个方向：一是回避内部，转向外部，通过增加服务器水平扩展Scalable；另外一种不使用多线程，而是使用单线程，比如Node.js。这些问题讨论可见我这个新帖：Why AsyncFP 引起的一场争论
[该贴被banq于2011-12-28 09:52修改过]

其次，我还想说的是，其实这个话题真的有点意思，初接触Java的时候，就在很多地方听过这么一句话，java是一种健壮的开发语言，虽然这个健壮有一些共性的理解，比如说异常处理机制等。但是其实我提的这个问题，应该可以算对健壮性的一个拓展的解决吧，比如你我他，咱们三个应用在同一个服务器上跑，公用一个数据库，如果说我比较“健壮”的话，和操作系统服务器数据库的关系还比较“铁”的话，按照这个逻辑，我一个人吃一碗饭，或者咱们三个人吃一碗饭，我都不用担心自己会吃不饱。近而可以联想到，程序的可靠性是不是大大增强，环境及时发生了预想的若干变化，我都有自身的适应能力，以保证我的任务始终都能顺利完整地完成呢？其实很多时候，我们都习惯于一遇到问题，赶紧从我们的程序里找问题，这当然也无可厚非，但是程序是否能很好地完成自己的使命任务，显然并不完完全全都取决于它自身，它也有自己的委屈和苦衷，也希望自己霸道一点，不变应万变。要达到这个期望目的，这个方向我个人觉得值得大家进一步探讨钻研。共勉吧，谢谢大家。

问题就出在“健壮”上面，由于健壮稳定需要，就特别耗资源和时间。你见到比较铁的哥们儿要多说几句话吧，这就耽误时间没空招待新来的其他朋友。

以TCP和UDP比较，TCP比UDP健壮，但是UDP要轻量性能高，UDP可以通过反复来避免健壮问题。
[该贴被banq于2011-12-28 17:10修改过]