背景：旧的接口是传统的两层架构设计，应用层+数据层。使用多台数据库来承载数据访问。问题是：
1、并发能力不够，业务请求分散无法通过增加有效的缓存来提升系统并发度。
2、大量的数据库冗余，无法分布式，即使业务访问量处于低峰，也占用资源，效率较低。
新架构目标：
1、提升系统并发度
2、提高系统可用性
3、降低成本
设计和实现：
通过使用NoSQL数据库的特性来替代关系性数据库，将关联查询分解。提高了系统并发度和可用性。Redis的主从复制功能方便的解决了数据一致性，并分担了负载。
优化之后应用层网络传输又成为下一道瓶颈。在高并发的情况下，多次的从Redis读数数据，即使使用长链接，也会有较大的网络开销。
通过Lua开发嵌入的Reids模块，在Redis内部将数据处理好后直接返回。将3次网络通讯降低到1次（了解TCP协议，自然明白这里节省的开销)，解决应用层数据传输的瓶颈。
通过性能和生产环境的可用性测试后，完成铺开。
分布式：
代码层来实现负载均衡和故障切换，灵活可控，完成分布式目的。当然也可以通过负载均衡来完成此目的。
高并发：
充分利用Redis的特性（内存，单线程，复制）提高降低关系型数据库以来，提高系统并发度。（推荐《Redis设计与实现》这本书)
应用和Redis之间采用长链接来优化网络效率，避免重复握手。
高可用：
通过“比赛日”测试，提高系统可用性。系统能达到“两次失误的高度”(引用《Architecting for Scale》)。当碰到系统故障或者流量激增，系统通过Auto Scaling自动扩展服务保证系统的可用性。接入Cloud watch和自监控系统，关注应用层响应时间，Redis状态等核心指标。
效果：
最终使用2台Redis服务器完成了过去9台主从数据库服务器的功能。接口响应时间缩短了一个数量级，并发度自然提高。便于全球多节点分布式部署和降低维护成本角
充分的AB实验得到数据，通过数据分析长链接效果更优秀和设置进程长链接持续时间和资源回收时间。
总结：
当然可以通过分布式来快速提升系统并发能力，但有能力寻找到系统瓶颈（一般是IO的瓶颈），然过合理的方案解决，往往事半功倍。
It's so tough to make a decision to rebuild old system.
I don't pay the bill.And this process may cost lots of time and mean nothing to somebody.
If you screw up, it's your problem.
But(there's always a but), I ain't here for work.But for something.
相关阅读
发表评论