第7章 分布式架构设计 【流量在5000万以上如何架构设计】

4、流量在5000万以上如何架构设计？

答：

（1）分布式缓存设计

提高系统吞吐量最有效的措施就是降低系统平均响应时间。

响应时间：就是从用户发出请求开始到最终获得系统反馈所需要的时间。

服务端的耗时主要分为两部分：数据存库前的耗时和存储数据库中的耗时。数据存库前要进行各种逻辑校验与业务操作。校验与操作的效率的决定性因素是那些为了完成校验和业务而进行的查询。所以，提高这部分操作的查询效率，才是性能提升的关键。

本地缓存：将应用服务器集群中每个节点本地的内存拿出一部分，将其作为缓存来存储数据。本地缓存有一个缺点，就是它的容量有限；如果缓存被写满后，需要运用最近最少使用算法删除一部分数据。缓存提升性能的关键是看“命中率”这个指标。

命中：就是当系统需要查询某条数据时，能够从缓存中找到这条数据。命中率越高性能越好。命中概率与哪些因素有关呢？首先看两次查询的间隔时间，间隔时间越短概率越高；其次是数据量，写入缓存的数据量小，删除的数据量就小，命中率就高；再次，就是缓存容量，缓存自身的容量越大，存储的数据就越多，命中率自然就得到提高。

分布式缓存：就是将缓存从应用服务器中分离出去，单拉出一些设备进行缓存 。与本地缓存相比，分布式缓存唯一的缺点就是需要网络访问，会损失一点性能。但是这点损失换来的是命中率高、可靠性高、可扩展性等诸多的优势。

 

（2）内存数据库

存储数据库部分，除了地数据库本身进行读写分离等优化措施外，还可以采用内存数据库。

内存数据库不是将所有数据都存储在内存的数据库，而是将一部分活动的数据存储在内存中进行快速访问。当活动数据逐渐冷却下来以后，最终还要被存储到传统数据库的磁盘中。

 

（3）异步化操作

异步化操作：通过消息队列将整个业务操作过程分为前后两个部分。前面受理阶段只做一些简单的事情，然后快速打包发送一个消息，就返回给用户，从而获得一个极快的响应速度与极高的系统吞吐量。

案例：12306订票系统

当用户发出订票请求的时候，首先由订票受理程序来接收请求。而订票受理程序接收请求后，只做一件非常简单的事，就是将用户请求打包成一个消息，发送到消息队列中。发送完消息后，订票受理程序的任务就完成了，立即返回给用户，从而获得一个非常快的响应速度。系统虽然通过订票程序完成了对用户的响应，从而获得了一个极高的系统并发，但是，用户还没有订到车票；因此，系统后台通过守护进程不断地从消息队列中读取消息，完成后续的订票处理程序。这时，原有的通讯信道已经结束 ，无法采用以往的方式反馈用户，只能另辟蹊径，采用APP推送、发短信、发邮件等其他方式通知用户。以上的设计过程，被称为“异步化操作”。

异步化操作的关键是分布式队列。