高并发
稳：高可用，系统稳定的提供服务。
准：超卖。数据一致性问题。
快：高性能。（优化的点）。
路径要短：每个节点可靠性：99%，5个节点：95%。分层过滤。
依赖要少：花里胡哨的减少。优先级高的展示，低的去掉。
不要单点：保证高可用：负载均衡，水平扩展，（replicates :3）。
用户--浏览器--DNS--CDN--负载均衡--网关--服务--IO
购买商品的流程：
下单扣库存，设置超时和中间状态，扣款。
若不设置超时，下单扣库存后，未付款，要把库存还原回去。这样会少卖，影响真正想买的人。
如果付款的时候再扣库存会出现超买。
钱到了第三方支付宝平台，但是支付宝平台没有给到卖家，设置预付，东西处于支付中。
可靠消息服务处理
构成元素：服务1，可靠消息服务，redis，MQ，mysql。
消息状态：待确认，已确认（取消），已发送，已完成。
- 服务1发送消息到可靠消息服务中，此时消息状态为待确认
- 服务1将数据写入redis，写入成功后，告诉可靠消息服务，此时消息状态为已确认 可靠消息服务先回查，再将消息送给MQ，此时消息状态为已发送 MQ的订阅者/消费者拿走消息，将数据写入mysql后告诉可靠消息服务，此时消息状态为已完成
其中1，2放在一个事务中处理。
可靠消息服务中还有个定时任务，是去轮询状态为待确认的消息，看是已确认还是取消
为什么要有一个待确认状态？
因为如果先db，再去发送消息到可靠消息服务，这样，有可能会存在网络等待时间太久的情况，这样之前db的IO时间就浪费了。所以先试探一下，这样成功的概率更高，db IO和网络等待的IO都不会被浪费掉。
如果消息已确认发到可靠服务中，或者发已取消到可靠服务中心，可靠服务执行完了，消息也存库了，可靠服务回消息的时候失败了。 现在可靠服务中的消息处于已确认或者已取消待发送的状态，那么在往MQ中写数据的时候再查一下。
如果可靠服务执行完了，服务1未得到响应，应该是在服务1的catch timeout语句里面要做相应的处理吧，直接给客户端返回一个结果
秒杀
概念：短时间（瞬时），大量请求，买一个（数量少）商品。
需要解决的问题：高并发的读和写。
秒杀系统的目标：
- 稳：高可用
- 准：不超卖。数据一致性问题
- 快：高性能
架构设计原则
- 减少用户和服务端的交互
- 数据要少: 请求参数和响应参数要少，这样可以降低对网络的占用，降低对cpu的消耗。非必要的信息不要来回发。还可以减少IO；
- 请求数要少：合并请求；
- 路径要短：
- 依赖要少：花里胡哨的减少。优先级高的展示，低的去掉。
- 保证高可用：负载均衡，水平扩展。不要单点 动静分离
数据区分：url，用户，浏览时间，地域，cookie（缓存信息），这些改变都不影响数据的获取，就是静态数据
把压力从自己的服务器，转移到用户的机器上
假如服务器只能处理10个请求
限流：来了11个请求，丢掉最后一个请求
削峰：来了100个请求，慢慢处理这100个请求
