1，使用异步通信
异步通信显然可以更快的返回响应。从实际经验看，对高吞吐服务器更大的好处是，系统中的某一服务出现问题后往往出现雪崩似的服务宕机。这很多都是由于采用同步通信，需要等待其他服务同步通信结束后，其占用资源才能得到释放。而这些资源往往是socket连接、线程、数据库连接等比较重的资源。因此请慎重使用同步通信。如果你真的需要他，可以用个mock同步。正如Tim Yang所说：很多远程服务调用是在关键路径中，它可以容忍失败，但是不能容忍堵塞。
2，使用NIO
NIO几乎是Java cluster的基石。大量分布式开源项目都基于此项技术。其好处是用较低的系统开销处理大量消息。在Intel(R) Pentium(R) 4 CPU 3.00GHz/1G内存的普通PC上跑基于NIO/TCP的RTSP测试，每秒处理1K个RTSP消息是没有问题的。关于NIO的架构可以参考开源项目MINA，但要注意的是，不要直接用处理NIO消息的线程处理逻辑。
3，尽量不使用锁
如果你在高性能服务器逻辑中看到同步锁，就要小心了。我们希望服务器可以同时并发的尽量多的处理请求，而同步锁恰恰摁住了业务的咽喉。同时如果线程设计有问题而导致大量线程争夺同一把锁，最坏的情况（超过1K+线程）我曾见过JVM要用几个小时来调度一个线程占锁（为什么？请牛人解释）。解决的办法就是：1，尽量不用。可能么？在一定程度上是可能的，比如我曾使用一致性哈希算法解决资源sticky的问题。用算法替代同步，是一个思路；2，尽量减少锁的范围，事同步锁影响的逻辑越少越好。效果也很明显；3，使用数据库更新替代同步也是一个思路，虽然我自己不是很喜欢，但是从实际效果看使用数据库，特别是用存储过程。在压力不大的情况也是个简单有效的方法。
4，减少GC
Full GC对Java服务器性能的影响是致命的，特别是当JVM管理着较大内存时。即使是在小型应用，例如Old区只分配512M内存，一次Full GC都可能耗时2~3秒，这意味着你所有的服务都会中断。尽量减少Full GC的次数绝对是我们的目标。
首先，合理的配置GC参数，采用ParallelGC和 ConcMarkSweepGC，即并发和增量GC。CMS，全称Concurrent Low Pause Collector，CMS用两次短暂停来替代串行标记整理算法的长暂停。
第二，打出GC log，在性能测试阶段，检查你的GC是否OK。系统在线测试时也可以提供宝贵的track。
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
给出一个实际服务器GC参数为例，
1
JAVA_OPTS=" -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+DisableExplicitGC
2
JAVA_OPTS=" -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=8
3
JAVA_OPTS="-Xms256m -Xmx640m -XX:NewSize=128m -XX:MaxNewSize=256m -Xss128k
4
JAVA_OPTS=" -XX:PermSize=64m -XX:MaxPermSize=128m
5
JAVA_OPTS=" -XX:SurvivorRatio=14 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=16
5，数据库前Cache
用queue缓存数据，一次写入多个数据。可以用多个线程同时写入数据库。在实际系统中，用多个线程同时读取cache并写入Mysql是效率很高的。
6，增加数据库索引
看起来很弱对吧？可是我真的遇到过靠加个简单的索引解决过一个很严重的性能问题。系统瓶颈的多数问题都存在于数据库和线程的使用不当上，所以还是要强调一下。
7，Master-Slave Mysql
Mysql有一篇很有名的文章来解释在Master-Slave结构下提高读效率的文章。大致就是说Mysql基准测试下max_read=1200次/s。在读写比例为9:1的情况下，通常写的时间比读的时间多一倍。假设有N个slave，如果只用slave来读，公式如下：
Max reads = 1200 – 2 * writes
Max Reads = 9 * writes / (N + 1) (读为9倍的写，平均到N+1个Mysql上)
9 * writes / (N + 1) + 2 *writes = 1200
Writes = 1200/ (2 + 9/(N+1))
结论是N=1，每秒增加到184次写
N = 8，增加到400次写
其中需要考虑的是复制多份binlog所占的网络带宽和对Master Mysql的影响。但我们在实际应用中认为mysql master-slave binlog增量同步是非常迅速且没有察觉到对性能的负面影响。但一般来说，既然memcached可以很好解决read问题，很少有team做这么大规模的mysql cluster。但小于等于4个还是可以考虑的。
总结，合理的使用异步通信，线程调度，优化GC和解决数据库瓶颈往往可以是构建高性能高并发Java消息处理服务器的利器。但这仅限于逻辑业务相对简单的即时通信系统，如果是设计大量cache调度，比如网页调度。或者是设计海量数据处理服务器，则需要考虑更多的问题。
本文纯属原创，基于实际系统经验，欢迎转载，请注明原网址；
我的新浪博客：http://blog.sina.com.cn/u/1793692835
异步通信显然可以更快的返回响应。从实际经验看，对高吞吐服务器更大的好处是，系统中的某一服务出现问题后往往出现雪崩似的服务宕机。这很多都是由于采用同步通信，需要等待其他服务同步通信结束后，其占用资源才能得到释放。而这些资源往往是socket连接、线程、数据库连接等比较重的资源。因此请慎重使用同步通信。如果你真的需要他，可以用个mock同步。正如Tim Yang所说：很多远程服务调用是在关键路径中，它可以容忍失败，但是不能容忍堵塞。
2，使用NIO
NIO几乎是Java cluster的基石。大量分布式开源项目都基于此项技术。其好处是用较低的系统开销处理大量消息。在Intel(R) Pentium(R) 4 CPU 3.00GHz/1G内存的普通PC上跑基于NIO/TCP的RTSP测试，每秒处理1K个RTSP消息是没有问题的。关于NIO的架构可以参考开源项目MINA，但要注意的是，不要直接用处理NIO消息的线程处理逻辑。
3，尽量不使用锁
如果你在高性能服务器逻辑中看到同步锁，就要小心了。我们希望服务器可以同时并发的尽量多的处理请求，而同步锁恰恰摁住了业务的咽喉。同时如果线程设计有问题而导致大量线程争夺同一把锁，最坏的情况（超过1K+线程）我曾见过JVM要用几个小时来调度一个线程占锁（为什么？请牛人解释）。解决的办法就是：1，尽量不用。可能么？在一定程度上是可能的，比如我曾使用一致性哈希算法解决资源sticky的问题。用算法替代同步，是一个思路；2，尽量减少锁的范围，事同步锁影响的逻辑越少越好。效果也很明显；3，使用数据库更新替代同步也是一个思路，虽然我自己不是很喜欢，但是从实际效果看使用数据库，特别是用存储过程。在压力不大的情况也是个简单有效的方法。
4，减少GC
Full GC对Java服务器性能的影响是致命的，特别是当JVM管理着较大内存时。即使是在小型应用，例如Old区只分配512M内存，一次Full GC都可能耗时2~3秒，这意味着你所有的服务都会中断。尽量减少Full GC的次数绝对是我们的目标。
首先，合理的配置GC参数，采用ParallelGC和 ConcMarkSweepGC，即并发和增量GC。CMS，全称Concurrent Low Pause Collector，CMS用两次短暂停来替代串行标记整理算法的长暂停。
第二，打出GC log，在性能测试阶段，检查你的GC是否OK。系统在线测试时也可以提供宝贵的track。
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
给出一个实际服务器GC参数为例，
1
JAVA_OPTS=" -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+DisableExplicitGC
2
JAVA_OPTS=" -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=8
3
JAVA_OPTS="-Xms256m -Xmx640m -XX:NewSize=128m -XX:MaxNewSize=256m -Xss128k
4
JAVA_OPTS=" -XX:PermSize=64m -XX:MaxPermSize=128m
5
JAVA_OPTS=" -XX:SurvivorRatio=14 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=16
5，数据库前Cache
用queue缓存数据，一次写入多个数据。可以用多个线程同时写入数据库。在实际系统中，用多个线程同时读取cache并写入Mysql是效率很高的。
6，增加数据库索引
看起来很弱对吧？可是我真的遇到过靠加个简单的索引解决过一个很严重的性能问题。系统瓶颈的多数问题都存在于数据库和线程的使用不当上，所以还是要强调一下。
7，Master-Slave Mysql
Mysql有一篇很有名的文章来解释在Master-Slave结构下提高读效率的文章。大致就是说Mysql基准测试下max_read=1200次/s。在读写比例为9:1的情况下，通常写的时间比读的时间多一倍。假设有N个slave，如果只用slave来读，公式如下：
Max reads = 1200 – 2 * writes
Max Reads = 9 * writes / (N + 1) (读为9倍的写，平均到N+1个Mysql上)
9 * writes / (N + 1) + 2 *writes = 1200
Writes = 1200/ (2 + 9/(N+1))
结论是N=1，每秒增加到184次写
N = 8，增加到400次写
其中需要考虑的是复制多份binlog所占的网络带宽和对Master Mysql的影响。但我们在实际应用中认为mysql master-slave binlog增量同步是非常迅速且没有察觉到对性能的负面影响。但一般来说，既然memcached可以很好解决read问题，很少有team做这么大规模的mysql cluster。但小于等于4个还是可以考虑的。
总结，合理的使用异步通信，线程调度，优化GC和解决数据库瓶颈往往可以是构建高性能高并发Java消息处理服务器的利器。但这仅限于逻辑业务相对简单的即时通信系统，如果是设计大量cache调度，比如网页调度。或者是设计海量数据处理服务器，则需要考虑更多的问题。
本文纯属原创，基于实际系统经验，欢迎转载，请注明原网址；
我的新浪博客：http://blog.sina.com.cn/u/1793692835
扫一扫
1593
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
