深入讲解交易系统设计原则——高并发原则

1.高并发原则

1.1无状态

如果设计的系统是无状态的，那么应用比较容易进行水平扩展。实际生产环境可能是这样的：应用无状态，配置文件有状态。例如，不同的机房需要读取不同的数据源，此时，就需要通过配置文件或配置中心来指定。

1.2拆分

在系统设计初期，是做一个大而全面的系统还是按照功能模块拆分系统，这个需要根据环境进行权衡。比如做一些交易量不大的系统，我们就没必要对系统进行细化的拆分了。但是像京东、淘宝之类的秒杀系统，访问量很大，就得按照功能来拆分了。

我们可以按照以下的情况来进行拆分：

• 系统维度：按照系统功能、业务进行拆分，例如商品系统、购物车、交易、订单系统。
• 功能维度：对一个系统进行功能再次拆分，比如，优惠券系统可以拆分为后台券发放系统、领券系统、消费券系统。
• 读写维度：根据读写比例进行拆分。例如，商品系统，交易的各个系统都会读取数据，读的量大于写，这时可以拆分成商品写服务；读服务使用缓存来提高效率；写的量比较大时，可以考虑分库分表；有些聚合读取的场景，如商品详情页，可以考虑数据异构拆分系统，将分散在多出的数据聚合在一处，以提升系统的性能和可靠性。
• AOP维度：根据访问特点，按照AOP进行拆分，例如，商品详情页可以分为CDN（也叫作AOP系统）、页面渲染系统。
• 模块维度：按照代码维护特征进行拆分，如基础模块分库分表、数据库连接池；代码结构一般按照三层架构（Web、Service、DAO）来设计

1.3服务化

首先，判断是不是只需要简单的单点远程服务调用，单机不行集群是不是就可以解决呢？在客户端注册多台机器并使用nginx进行负载均衡是不是可以解决呢？随着调用方越来越多，应该考虑使用服务自动注册和发现（Zookeeper和Dubbo）。其次，还要考虑服务的隔离，如果有的系统模块访问量很大，有可能会把整个系统拖垮，所以我们还要为不同的调用方提供不同的服务分组，隔离访问。后期，随着调用量的增加还要考虑服务的限流、黑白名单等。还有一些细节要注意，例如超时时间、重试机制、服务路由、故障补偿，这些都会影响到服务的质量。

概括上面一段话：进程内服务——>单机远程服务——>集群手动注册服务——>自动注册和发现服务——>服务的分组/隔离/路由——>服务治理限流/黑白名单

1.4消息队列

消息队列用来解耦一些不需要同步调用的服务或者订阅一些自己系统关心的变化。使用消息队列可以实现服务解耦、异步处理、流量缓冲等。例如，在电商系统中的交易订单数据，该数据有非常多的系统关心并订阅。再例如，订单生产系统、订单风控系统等。如果订阅者太多，那么订阅单个消息队列就会成为系统瓶颈，此时，需要考虑对