浓缩精华的架构演进过程( 二 ) _架构

用户请求访问数据的顺序为客户端浏览器缓存→应用服务器本地缓存→缓存服务器缓存。
如果按照以上次序还没有命中数据，才会访问数据库获取数据。加入缓存的设计，提高了系统的性能。
由于缓存放在内存中，而内存的读取速度比磁盘要快得多，能够很快响应用户请求。
特别针对一些热点数据，优势尤为明显。同时，在可用性方面也有明显的改善。
即使数据库服务器出现短时间的故障，缓存服务器中保存的热点或者核心数据依旧可以满足用户暂时的访问。当然，后面还会对可用性进行优化。
服务器集群的加入
经过前面三个阶段的演进，系统对用户的请求量有了很好的支持。实际上，这都是在解决高性能和可用性的问题，这一核心问题会一直贯穿整个系统架构的演进过程中。
随着用户请求量的增加，另外一个问题又出现了，那就是并发。把这两个字拆开了来看：并，理解为“一起并行“，有同时的意思;发，理解为“发出调用”，也就是请求的意思。
合起来就是多个用户同时请求应用服务器。如果说原来的系统面对的仅仅只是大数据量的话，那么现在就需要面对多用户同时请求。
如果还是按照上一个阶段的架构图推导，单个应用服务器已经无法满足高并发的要求了。
此时，服务器集群就加入战场了，其架构图如图 4 所示：

文章插图

图 4：服务器集群的加入
服务器集群也就是多台服务器扎堆的意思，用更多的服务器来分担单台服务器的负载压力，提高性能和可用性。
再说白一点，就是提高单位时间内服务处理请求的数量。原来是一个服务器处理，现在是一堆服务器来处理。就好像银行柜台一样，增加柜员的人数来服务更多的人。
这次架构演进与上次相比，增加了应用服务器的个数，用多台应用服务器形成集群。
应用服务器中所部署的应用服务没有改变，在用户请求与服务器之间加入了负载均衡器，帮助用户请求路由到对应的服务器中。增加服务器的举动表明，系统的瓶颈是在处理用户并发请求上。
针对数据库和缓存都没有做更改，这样仅仅通过增加服务器数量就能够缓解请求的压力。
服务器集群会通过多台服务器来分担原来一台服务器需要处理的请求，在多台服务器上同时运行一套系统，因此可以同时处理大量并发的用户请求。
有点三个臭皮匠顶个诸葛亮的意思，因此对集群中单个服务器的硬件要求也会降低。此时需要注意负载均衡均衡的算法，例如轮询和加权轮询。
我们要保证用户请求能够均匀分布到服务器上面，同一个会话的请求保证在同一个服务器上面处理，针对不同服务器资源的优劣动态调整流量。
负载均衡器加入之后，由于其位于互联网与应用服务器之间，负责用户流量的接入，因此可以对用户流量进行监控，同时对访问用户的身份和权限进行验证。
数据库读写分离
加入缓存可以解决部分热点数据的读取，但缓存数据的容量有限，那些非热点的数据依旧会从数据库中读取。数据库对于写入和读取的性能是不一样的。
在写入数据的时候，会造成锁行或者锁表，此时如果有其他写入操作并发执行，会存在排队现象。
而读取操作比写入操作更加快捷，并且可以通过索引、数据库缓存等方式实现。
因此，推出了数据库读写分离的方案，其架构图如图 5 所示：

文章插图

图 5：数据库读写分离
此时设置了主从数据库，主库(master)主要用来写入数据，然后通过同步 binlog 的方式，将更新的数据同步到从库(slave)中。
对于应用服务器而言，在写数据的时候只需要访问主库，在读数据的时候只用访问从库就好了。
利用数据库读写分离的方式，将数据库的读/写职责分离。利用读数据效率较高的优势，扩展更多的从库，从而服务于读取操作的用户请求。毕竟在现实场景中，大多数操作都是读取操作。
此外，从数据同步技术的角度来说，又可以分为同步复制技术、异步复制技术和半同步复制技术。在数据库读写分离带来益处的同时，架构也需要考虑可靠性的问题。
例如，主库如果挂掉，从库如何接替主库进行工作。主库在恢复以后，是成为从库还是继续担当主库，以及如何同步数据的问题。