亿级流量网站架构核心技术笔记

第一章  交易型系统设计的一些原则

    1.1 高并发原则

             1.1 高并发原则

                 1.1.1 无状态

                                 如果设计的应用是无状态的，那么应用比较容易进行水平扩展。实际生产环境可能是这样的：应用无状

                              态，配置文件有状态。比如，不同的机房需要读取不同的数据源，此时，就需要通过配置文件或配置中心指

                              定。

                              关于有状态的应用指的是session，无状态的应用指的是session，具体查看博客

                              https://blog.csdn.net/kikajack/article/details/80293328

                              这里只说下session的缺点：

                              --  服务器压力大：每个用户在认证后，Session 信息都会保存在服务器的内存中，开销大。

                              --  难以扩展：对于基于 Session 的分布式系统，要实现负载均衡，有两个办法：确保同一用户始终访问同一

                                                    个服务器，或在多台服务器之间同步 Session。对于前者，Nginx 也可以用 ip_hash 把同一来源

                                                    的 IP（同一 C 段）指向后端的同一台机器。对于后者则需要通过 Session Sticky 机制在多台服

                                                    务器之间同步 Session（例如 Nginx 的扩展模块 nginx-sticky-module。假设 Session 存储在A服

                                                    务器上，而用户访问了 B 服务器，则可以将 Session 从 A 同步到 B，但是如果存储 Session的A

                                                    服务器挂掉，还是会导致用户掉线）。

                 1.1.2 拆分  

                                 笔者遇到的拆分主要有如下几种情况。

                                      系统维度：按照系统功能/业务拆分，比如商品系统、购物车、结算、订单系统等。

                                      功能维度：对一个系统进行功能再拆分，比如，优惠券系统可以拆分为后台券创建系统、领券系统、用券

                                                        系统等；

                                      读写维度：根据读写比例特征进行拆分。比如，商品系统，交易的各个系统都会读取数据，读的量大于写，

                                                        因此可以拆分成商品写服务、商品读服务：读服务可以考虑使用缓存提升性能；写的量太大时，

                                                        需要考虑分库分表；有些聚合读取的场景，如商品详情页，可考虑数据异构拆分系统，将分散

                                                        在多处的数据聚合到一处存储，以提升系统的性能和可靠性；

                                      AOP维度：根据访问特征，按照AOP进行拆分，比如，商品详情页可以分为CDN、页面渲染系统；CDN

                                                         就是一个AOP系统。

                                      模块维度：比如，按照基础或者代码维护特征进行拆分，如基础模块分库分表、数据库连接池等；代码结

                                                        构一般按照三层架构(web、Service、DAO）进行划分。

                                      模块维度：比如，按照基础或者代码维护特征进行拆分，如基础模块分库分表、数据库连接池等；代码结

                                                        构一般按照三层架构(web、Service、DAO）进行划分。