第一章 交易型系统设计的一些原则
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)进行划分。