----------------------------------架构评测---------------------------------------
1. 高并发：通过设计保证系统能够同时并行处理很多请求
总原则：水平扩展 + 垂直扩展
水平扩展包括：做集群；
垂直扩展包括：增强单机硬件性能和提升单机架构性能，如使用缓存来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
具体详解：
(1)缓存：HTTP缓存：浏览器缓存，Nginx代理层缓存
java缓存：堆缓存(Ehcache\mapDB)、堆外缓存(Ehcache\mapDB)、磁盘缓存(Ehcache\mapDB)
分布式缓存：Redis( 注：详见《亿级流量网站架构核心技术》9.4)
(2)异步调用：提高吞吐量
(3)锁：使用无锁数据结构来减少响应时间，减小锁持有时间、读写分离锁、锁粗化、JVM增加锁消除和取消锁偏向（并发高的情况）；
(4)池：对象池、线程池、连接池(HTTP连接池、Redis连接池、数据库连接池)
(5)集群：
接入层：集群，通过"DNS轮询"，增加反向代理nginx的数目，dns-server对于一个域名配置了多个解析ip
应用层：集群，通过nginx的nginx.conf实现，设置多个后端；
服务层：集群，通过服务连接池实现，站点层通过RPC-client调用下游的服务层RPC-server时，RPC-client中的连接池会建立与下游服务多个连接，当服务成为瓶颈的时候，只要增加服务器数量，新增服务部署，在RPC-client处建立新的下游服务连接，就能扩展服务层性能，做到理论上的无限高并发。如果需要优雅的进行服务层自动扩容，这里可能需要配置中心里服务自动发现功能的支持。
数据库：分库分表+读写分离+缓存，数据库可通过范围拆分和哈希拆分方法进行水平拆分；如读多写少的冷数据可配置大量从库来化解查压力，对读多写多的热数据可使用多个主库构建分库分表，特殊热点数据，可使用Redis等缓存，累计到一定后再更行数据库；
缓存：分片+多级缓存，通过分片来分割大数据的查询，通过主从来完成高可用和部分高性能需求，多个副本化解查询压力；
消息队列：分区，通过多服务器且分区方式提高消息队列吞吐量，详见kafka原理；
注：https://blog.csdn.net/u010370157/article/details/77870468 高可用+高并发+负载均衡架构设计 ---- 好！！
https://blog.csdn.net/csdn265/article/details/70234156 架构学习之路—高可用高并发系统设计原则 ---- 好！！
2. 高可用：
(1) 总原则：水平扩展(即冗余+自动故障转移) + 垂直扩展
接入层高可用：失效转移，有两台nginx，一台线上提供服务，另一台冗余，常用keepalived存活探测+相同virtual IP提供服
应用层高可用：负载均衡的失效转移、限流
服务层高可用：负载均衡的失效转移、异步调用、超时设置、服务降级、幂等性设计、限流、分级管理
数据层高可用：数据备份、限流、CAP原理
缓存高可用：回源+主从(即主备、哨兵机制)，通常缓存不用做高可用方案，因为可回源；
消息队列高可用：主从，即根据配置每个分区还可以复制到其它服务器作为备份容错，每个分区有一个leader，零或多个follower。Leader处理此分区的所有的读写请求，而follower被动的复制数据。如果leader宕机，其它的一个follower会被推举为新的leader。 一台服务器可能同时是一个分区的leader，另一个分区的follower。---- 需要zookeeper配合
（注：失效转移可通过Nginx或zookeeper等来实现；
（https://blog.csdn.net/chenxun_2010/article/details/78374278 高可用架构之高可用的应用和服务
(2) 接入层失效转移：
(3) 缓存高可用：数据备份或一主两从
一般不做缓存高可用，因为可回源；
主从模式+哨兵机制：如redis天然支持主从同步，redis官方也有sentinel哨兵机制，来做redis的存活性检测；当redis主挂了的时候，sentinel能够探测到，会通知调用方访问新的redis；----需用jedis2.2.2后版本实现通知应用程序，可不用zookeeper
(4) 数据库高可用：
写库的高可用：是通过写库的冗余实现的，方法一：keepalived + virtual IP自动故障转移，为解决数据一致性问题，可通过内网DNS检测，不适用相同虚拟IP，而是IP1和IP2，小脚本检测主库1连通性，在主库1出现问题后延时一段时间再进行主库切换；方法二：通过双主同步，设置相同不同初始值+相同步长，和全局唯一ID，来避免主键冲突；
读库的高可用：是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移；
其他：数据备份一般为一主一备，读写分离一般为一主两从；
详见：58沈剑-Mysql双主一致性架构优化
2. 其他高可用
(1) 简介：
大流量和高并发环境下保持系统稳定性方法：限流、动静分离、扩容、降级、缓存
(2)限流/削峰：
a. 限流算法：
令牌桶算法：Guava，可实现平滑限流，平滑突发限流和平滑预热限流
漏桶算法：基于消息队列限流
计数器算法：连接池
b. 限流层次：
应用层限流：详见《亿级流量网站架构设计》4.2
分布式限流：Redis+Lua或Ngix+Lua
接入层限流：ngx_http_limit_conn_module、ngx_http_limit_req_module、lua_resty_limit_traffic
c. 消峰方法：基于时间片消峰(活动分时段或答题验证)、基于消息中间件消峰
d. zxb总结削峰限流方法：
接入层：基于时间片削峰(活动分时段或答题验证)、Nginx的limit_conn和limit_req模块
应用层：页面里面用户点击查询或下单后将按钮置灰
其它层：令牌桶算法、漏桶算法(消息队列)、计数器算法(数据库连接池、线程池)
参照：https://blog.csdn.net/weixin_29135773/article/details/60764426 Nginx limit模块
(3) 动静分离：
CDN/反向代理、启用压缩、减少cookie传输、减少HTTP请求
(4) 高并发读：
加缓存，为避免大促场景下的读单点瓶颈，可：多读多写缓存、或多级缓存(LocalCache+Redis)
(5) 高并发写：
从缓存扣库存，并采用分布式乐观锁保证数据一致性
提升写入性能 : 写缓存，先收集写请求，达到阈值后做合并处理，最后批量提交
写数据库，可采用阿里的AliSQL关系数据库，原理同上
库存扣减方案：普通方案1. 扣减DB库存，扣减成功后，更新redis中的库存(可以使用binlog异步更新--58沈剑)
普通方案2. 扣减redis库存，同步扣减DB库存，如果扣减失败，则回滚Redis库存
普通方案3：对于普通读多写少的数据更新，可通过先淘汰redis，再写DB----58沈剑
优化方案1. 扣减redis库存，发一条扣减DB库存信息，异步进行DB库存扣减实现最终一致性
优化方案2. 扣减redis库存，等峰值过去后，再同步回DB
避免超卖 : a.数据库中扣减可采用乐观锁(加版本号字段，如果被修改过，即与redis读出的不一样，则进行处理)，
或可在扣减商品时判断“实际库存数>=扣减库存数”
b.缓存中扣减可依赖分布式锁(Redis或zookeeper可提供)---乐观锁
注：乐观锁与悲观锁：http://www.digpage.com/lock.html
乐观锁和悲观锁：乐观锁适用于写少的场景、悲观锁适用于写多的场景；
(6)降级：
接入层降级、页面层降级、应用层降级(包含服务层)、数据层降级
降级手段包括：通过配置中心开关手动降级、自动降级(如根据超时时间Hystrix)、同步改异步
详见《亿级流量网站架构核心技术》第5章
接入层降级开关：
(7)超时与重试：
接入层超时(ngix)、页面层超时(ajax)、应用服务层超时(web容器和各类中间件)、数据层超时(DB和NoSql)
详见《亿级流量网站架构核心技术》第6章
(8)一致性 & 分布式事务:
简介：TX协议定义了应用程序和事务管理器之间的接口，XA协议定义了事务管理器和资源管理器之间的接口；
a. 强一致性协议：不建议使用，如两阶段提交协议(准备+提交)、三阶段提交协议(询问...)、TCC(阿里)、Paxos、ZAB、Raft等；
2P&3P&TCC的大体都是需要一个协调者来协调各个参与者进行执行，缺点是实现复杂，性能较低；2PC存在单点、阻塞、脑裂(只一部分参与者接受并执行了事务)问题；3P相比2P增加了询问阶段和超时自我处理，避免了阻塞和永远锁定资源，两者都存在极端情况的一致性问题；
Paxos引入过半理论和分布式角色之间的轮换，避免了分布式单点出现，故即解决了无线期等待问题，也解决了脑裂问题，zookeeper使用的是paxos；Raft协议与paxos算法类似，但比paxos算法好理解，我们都知道，paxos算法是经典的分布式一致性算法zookeeper的ZAB协议也是在其基础上设计的。ZAB，paxos，Raft都是采用过半策略；
参考：https://www.zhihu.com/question/36648084 raft算法与paxos算法相比有什么优势，使用场景有什么差异？
b. 最终一致性：包括补偿模式、本地事务表/事务日志、定期校对模式、异步确保模式、可靠消息模式、最大努力保证模式(即后置提交)；
补偿机制：执行/回滚；//优点是实现简单，缺点是业务耦合性高，串行服务多回滚成本高；
本地事务表/日志：建立本地事务日志或事务表，并和业务操作放在一个事务里(因为事务嵌套RPC是大忌，会有长事务死锁等各种风险)，在遇到问题时，本地事务日志或事务表记录问题的环境信息等，后续分析记录进行补偿；//频繁读写消息对数据库造成很大压力；
定期校对模式：通过定期扫描优惠券和库存表，回滚没有关联订单的记录；
最大努力保证模式(即后置提交)：在更新多个资源时，将多个资源的提交尽量延后到最后一块处理，能降低不一致性发生概率；
异步确保模式：即将任务进行持久化，后定期捞取任务进行执行；
可靠消息模式：即事务性消息，方法一，本地消息表，即将业务操作和记录本地消息放在一个事务里，然后发送消息并修改状态//缺点是数据库性能瓶颈，频繁读写消息对数据库造成很大压力；方法二，先发送预消息给消息管理器，然后执行事务，最后发确认消息修改消息状态和真正消息，如果最后消息发送失败，则消息管理器通过定期扫描事务消息，向消息发送者确认事务是否执行成功来决定回滚还是发确认消息//缺点是实现难度比较大；对于可靠性要求低的非事务消息，可使用补偿机制，即发送消息失败则回滚模式//缺点是可靠性较低；
注：通常将补偿机制和本地事务表/事务日志一块使用；
参考：http://baijiahao.baidu.com/s?id=1596808295402419280&wfr=spider&for=pc 本地消息表（异步确保）---好！
https://www.cnblogs.com/guyun/p/6251742.html --- 分布式系统事务一致性解决方案 丁浪 -好！
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency -- 同上 丁浪- 好！
d. 分布式订单场景：
e. 转账场景
与扣钱的业务操作同一个事务里，将消息插入本地数据库。如果消息入库失败，则业务回滚；如果消息入库成功，事务提交。然后发送消息（注意这里可以实时发送，不需要等定时任务检出，以提高消息实时性）。这里有一个关键的点，本地事务做的，是业务落地和消息落地的事务，而不是业务落地和RPC成功的事务。这里很多人容易混淆，如果是后者，无疑是事务嵌套RPC，是大忌，会有长事务死锁等各种风险。而消息只要成功落地，很大程度上就没有丢失的风险（磁盘物理损坏除外）。而消息只要投递到服务端确认后本地才做删除，就完成了producer->broker的可靠投递，并且当消息存储异常时，业务也是可以回滚的；本地事务存在两个最大的使用障碍：
配置较为复杂，“绑架”业务方，必须本地数据库实例提供一个库表。
对于消息延迟高敏感的业务不适用。
话说回来，不是每个业务都需要强事务的。扣钱和加钱需要事务保证，但下单和生成短信却不需要事务，不能因为要求发短信的消息存储投递失败而要求下单业务回滚。所以，一个完整的消息队列应该定义清楚自己可以投递的消息类型，如事务型消息，本地非持久型消息，以及服务端不落地的非可靠消息等。对不同的业务场景做不同的选择。另外事务的使用应该尽量低成本、透明化，可以依托于现有的成熟框架，如Spring的声明式事务做扩展。业务方只需要使用@Transactional标签即可。
(9)幂等性设计：
对一个服务进行一次请求或者多次请求的结果是一致的
包括：查询（天然幂等），插入（使用全局ID，插入前先判断ID是否存在，如插入订单或防止消息消费重复），更新（使用版本号或状态机来控制）
参见：https://blog.csdn.net/wangyan9110/article/details/70953273 如何保证微服务接口的幂等性 -- 好！！！
3. 可伸缩
4. 可扩展
5. 安全性
https://mp.weixin.qq.com/s/5aMN9SqaWa57rYGgtdAF_A 秒杀系统架构优化思路 沈剑 好！！！
http://www.sohu.com/a/210488190_411876 58速运订单调度系统架构演进 -- 好！！！
https://www.jb51.net/article/77560.htm 限时抢购秒杀系统架构分析与实战 --好！！
https://blog.csdn.net/psiitoy/article/details/73201114 浅谈电商库存模型 -- 好！！
https://blog.csdn.net/csdn265/article/details/70188121 京东高并发抢购系统的核心逻辑与架构实现
https://blog.csdn.net/wwd0501/article/details/78052668 京东到家库存系统架构设计
http://bbs.paidai.com/topic/1512769 揭秘京东搜索千亿商品系统核心权重架构原理！！