读书笔记：交易型系统设计的通常原则

系统设计的通常原则

1.高并发原则

1.1无状态

应用应该被设计成为无状态的，这样应用也比较容易进行水平扩展。实际生产系统一般被设计成为应用无状态，配置有状态，那么只须要经过配置文件或配置中心指定便可。

1.2拆分

根据实际状况进行系统拆分，若是系统使用人员较少，并发不高，彻底没有压力作一个大而全的系统也无可厚非。

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

功能维度：好比对一个业务系统优惠券进行再拆分，后台券建立系统、领券系统、用券系统。

读写维度：根据读写比例特征进行拆分。好比，商品系统，交易的各个系统都会读取商品系统数据，读的量远远大于写的量，能够拆分红商品读系统，商品写系统；读系统能够经过缓存提高性能。写的量大时能够考虑分库分表。

1.3服务化

进程内服务--》单机远程服务--》集群手动注册服务--》自动注册和发现服务--》服务的分组/隔离/路由--》服务治理如限流黑白名单。

1.4消息队列

解耦一些不须要同步调用的服务或一对多订阅模式服务。使用消息队列能够起到服务解耦、异步处理、流量削峰和缓冲等做用。要考虑的问题：1订阅者太多致使单个消息队列成为瓶颈，须要对单个消息队列进行镜像复制。2消息重复接受问题须要进行一些防重处理。3消息接受失败问题须要进行告警和处理后续失败问题。

大流量缓冲：在流量特别高时能够考虑牺牲掉强制一致性，而保持最终一致性。好比扣减库存，能够先在redis中进行扣减，记录日志，同时使用异步的方式经过worker同步到DB。同时对队列中的消息最好加上处理人、正在处理、已处理、处理失败、失败次数等字段。

数据校对：在使用了消息异步机制的场景下，可能存在消息丢失，因此按期进行数据校对是颇有必要的。

1.5数据异构

数据异构：订单的分库分表通常按照订单ID进行分，若是要查询某个用户的订单列表则须要聚合多个表的数据后才能返回，这样就致使订单表读性能比较低，此时就须要对订单表进行异构处理，按照用户ID异构出一套用户订单表，按照用户ID进行分库分表。数据的异构通常是经过消息队列进行操做。

数据闭环：数据异构--》数据聚合--》前段展现。

数据聚合指的是把动不一样源拿过来的数据聚合到一块儿存储，而后到用时直接一次性放回全部使用到的数据。

1.6缓存银弹

1.浏览器缓存：对实时性不是很敏感的数据作浏览器缓存，如商品详情框架、商家评分、评价、广告词等。但对价格、库存等实时性要求比较高的数据，不能使用浏览器缓存。

2.APP客户端缓存：在大促活动前将js/css/img等静态资源提早下发到客户机上面，这样在大促时就不用重新从服务端拉取。还好比对首页或则地图等离线缓存。

3.CDN缓存：将一些静态页面、图片等能够考虑推送到离用户最近的CDN节点，让用户在离他最近的CDN节点找数据。CDN缓存通常有两种机制：第一种（推送机制）当内容变动主动推送到每一个CDN节点。第二种（拉取机制）当访问的URL资源在CDN节点没有时直接从源服务器拉取，并存储到CDN节点。使用CDN节点须要注意URL中不能有随机数，否则每次的URL都不同，每次都穿透CDN到源服务器取资源。

4.接入层缓存：若是没有CDN缓存能够考虑使用NGINX搭建一层接入缓存。

5.引用层缓存：也就是咱们使用Tomcat时，可使用堆内缓存/堆外缓存，堆内缓存的最大问题就是重启时会清空缓存，因此能够考虑使用local redis代替堆外缓存，多个主机须要主从机制同步数据。

6.分布式缓存:若是缓存数据量比较大就须要使用分布式缓存，常见的分片规则就是一致性hash。

1.7并发化

当须要的数据是从多个源获取时，可使用多线程并发从多个源获取数据，最终聚合数据展现。

2.高可用原则

2.1降级

对于一个高可用服务，很重要的一个设计就是在特殊状况下服务进行降级使用，以保证业务正常进行。

对于降级的思路有：

1开关集中化管理，把各系统的开关放到配置中心管理，由配置中心主动推送到各个应用使用。

2降级使用的状况，如正常状况下应用从本地缓存读取数据，在本地内存压力比较大的时候能够降级使用，设置为制度redis缓存，甚至不读缓存直接读取默认拖底数据。

3.开关前置化处理，如架构为Nginx->Tomcat时，开关能够设计在Nginx层，这样当Nginx进行流量控制以后Tomcat应用受到的就是较少的流量。

4.业务降级使用，好比在电商大促期间为了保证用户下单和支付等核心业务正常运行，能够把其余系统的降级使用，好比同步调用改为异步调用或能够暂时不保证数据实时一致性可是保证数据最终一致性。

2.2限流

限制流量能够防止流量超出峰值，且也能够防止恶意流量攻击等。

限制流量思路：最终目的是限制流量穿透到后端应用层，形成较大压力。

1恶意请求只访问到cache，不穿透到后端应用。

2.对于穿透到后端应用的流量进行Nginx的limit模块限制处理。

3.对于恶意IP可使用nginx deny进行屏蔽处理。

2.3切流量

切流量及在各流量入口作流量分配

DNS：切换机房入口

HttpDNS：在APP场景下，在客户端就分配好流量入口，绕过运营商LocalDNS，实现更精确流量调度。

LVS/HaProxy：切换故障的接入层Nginx

Nginx：切换故障的应用层。

2.4可回滚

设置发布版本、数据版本机制，在系统出现故障时及时回滚到最近一个正常版本上。

3业务设计原则

3.1.防止重复提交设计

3.2幂等操做设计

3.3流程可定义

3.4状态和状态机

3.5后台系统操做可反馈

3.6后台系统审批化

3.7文档和注释

3.8备份