原创力文档- 1、本文档共21页，可阅读全部内容。
- 2、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。
- 3、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 5、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 6、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
大集群的设计
2014.12.02
大集群的设计
整体架构
大集群要解决的问题
大集群的测试
集群星型互通方案
集群
Uc客户端
UC服务器
文件服务器
集群
Phone
client
DB
移动服务器
集群
集群
AD
F5
在线公司、集团公司、产险公司、寿险公司
DNS服务器
集群
UC服务器
集群
UC服务器
F5
DMZ
公网
集群
集群
UC服务器
client
分公司UcSTAR服务器
……
星型互联互通服务
单台
旧的系统架构对接
整体架构
大集群要解决的问题
集中配置
高性能
高可用(HA)
高可扩展
IM-Node
1：zookeeper处理集群统一配置文件问题
2：开发NodeManager管理这些节点的配置，配置统一放zk
Zookeeper配置服务器
大集群-集中配置
Node(Config)manager
zkclient
IM-Node
zkclient
IM-Node
zkclient
IM-Node
zkclient
zkconfigload
Http-Statulog
1：ucstarserver.xml配置
2：ehcache.xml缓存配置
3：数据库属性配置
4：ucstar.sh配置
zookeeper统一集群配置
所有服务器的集群配置直接访问zookeeper服务器，通过在xml中增加zookeeper的配置来完成
启动的时候加载zookeeper的配置(JSON)格式，然后将配置写到相应的ucstarserver.xml、ehcache.xml
IMNode1
IMNode2
Zookeeper配置服务器
Zkconfigmanager
NodeMgr
JettyStart
Zookeeper
Clientconn
savexml
Normalstart
统一集群配置细节
高性能
缓存优化
LocalCache方式
减少不必要的缓存通知开销
优化缓存通知，大部分缓存不需要通知
修改重点缓存处理(Properties)，撇开ehcache，采用自定义缓存共享策略
面临问题：LocalCache过大的问题、服务器海量后的缓存通知，由于企业内部不存在海量服务器部署的情况，因此可不用考虑缓存分布式分离。
IO优化
文件处理独立
服务器间有问题数据的过滤
减少数据库的读取和存储
同步/异步处理
缓存取消部分同步锁
服务器间调用改用异步RMI方式
缓存方案考虑
对比测试ehcache和hazelcast，结果ehcache并发性还是要好一些，传输海量数据更快
暂时保留选择ehcache缓存
减少cluster中ehcacheRMI缓存链接的数量，目前统计可以精简到20个左右，10台服务器就是200个rmi的url地址。
RMI访问地址端口重用机制，10个服务器之间的RMI连接只会生成10个Socket到服务器，所以不存在问题。而本地绑定石20个线程的RMI异步请求。
Ehcache旧版本的缓存通知机制采用List方式，数据容易被修改，后面采用Queue，避免Concurrent的错误，提高错误处理能力。
高可用(HA)
IMNode采用集群设计，全对等结构
任何服务器宕机都不影响整体的运行
IMNode之间通信的容错处理
服务器的检查在每台机器上都存在
NodeManager(zkconfig)监控IMNode的状态
数据一致性
统一数据库的存储
重要缓存数据的保护容错，例如Session信息，为了保持一致性，在各个服务器之间做Session的握手共享。
高可用-容错(宕机/OOM)
5273端口握手保持正常使用。
5099的RMI调用改成异步方式(采用Queue的异步处理)
Session会话握手处理，读取其他服务器的缓存session列表用于采集握手：服务器启动的时候会读取其他服务器的session列表、服务器(一体机)10分钟线程握手其他服务器的session会话列表信息；
10分钟检测直接放到核心系统中，一体机中取消该线程的使用
修改了工程的架构，将RMI、多服务器、星型管理放到了base工程中，以方便进行发布和管理。
服务器出现问题的指标：1:登陆协议阻塞;2:内存溢出;3:数据库连接池阻塞
每台服务器自己进行健康检查，并检查其他服务器的健康情况，保证不健康的情况下及时切断与服务器的连接
协议阻塞程序和内存溢出程序的开发
测试服务器的容错处理
高扩展
通过增加新的服务器提高服务器的性能
新加服务器后需要配置中心添加进来
所有服务器需要进行重启以完成对新服务器的配置添加
由于服务器之间集群采用Replate方式，之间存在缓存数据的共享存储，因此不支持海量服务器的环境，服务器控制在30台以内较为合适
目前未采用平滑扩展方案，该方案有待进一步的改进
大集群测试方案
测试程
文档评论（0）