独角兽企业重金招聘Python工程师标准>>>
系统设计的一般原则
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备份
