如何设计一个抢红包系统，或者是一个商城秒杀系统，设计的时候又需要重点关注那些业务。
以上两种系统类型，在一个时间点，会有请求激增的情况出现，且数量远远大于库存或者预定个数的数量，也就是说，只有少部分的用户能够抢到红包或者秒杀到商品，整个业务流程的话相对来说不会非常复杂。
友好的用户体验
- 用户不能接受破窗的体验，例如：系统超时、系统错误的提示，或者直接 404 页面
瞬时高并发流量的挑战
- 木桶短板理论，整个系统的瓶颈往往都在 DB，如何设计出高并发、高可用系统？
针对上面几个特点，系统的设计就要着重于抗住短时间内大量的请求，且能够保证商品数的扣减不会出现超扣的情况，也就是说我们要设计的是高并发以及高可用的系统。
关于这类系统的设计，有以下几个方面可以着重考量
前端：
页面静态化：
将活动页面上所有可以静态的元素全部静态化，并且尽量减少动态元素，通过浏览器的缓存技术，避免网页的重复请求，提高效率。
CDN加速：
即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。
用户限流：
这里也可以是防止用户短时间内的多次提交请求，这里通过IP限流或者表单提交来防止用户短时间内点击多次的重复请求。
后端
横向拓展：
服务的可扩展，可以水平添加机器将用户请求分担到不同的机器上去。数据库可扩展，支持分库分表，对于用户的请求，映射到不同的数据库，减少单台数据库的压力。分库分表如何去分，一般从业务上进行垂直拆分，如果业务单一，也可从水平上进行拆分。拆分的原则一般是：避免跨数据库事务和如何选择 shardingId。跨数据库事务可以选择在前期调研时把同一事务中的表放在一个数据库中。如果数据冷热不均 shardingId 可以是 UserPin 或者订单号 Hash 打散后的值，如果数据冷热均匀可以按段分库也可以对某一个值取模后的值。
拆分系统之后也有导致整个系统的复杂度提高，是同步还是异步，强一致性还是弱一致性，这些都是需要根据业务所具体讨论的。
内存缓存：
参加秒杀系统的商品是事先可知的，可以将参加秒杀的商品信息事先缓存到redis等缓存系统中，这样可以大大的提高系统的吞吐量，减少关系型数据库的读写压力。
在数据库层之上加一层缓存，减少对数据库的访问压力。缓存中的数据都是存储在内存里的，而数据库中的数据是写在磁盘上的，访问内存肯定是比访问磁盘快的可不止一个数量级。
大部分的高并发场景，都是读多写少，那我们完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟 redis 轻轻松松单机几万的并发。所以可以考虑考虑在项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发。
这里的话可以简单提提缓存雪崩、缓存击穿以及缓存穿透，用于短时间内大量的请求，所以很容易出现这些问题，特别是缓存击穿和缓存穿透，所以这里在对缓存的维护也需要多多关注。
削峰：
数据库削峰。对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。对于关系型数据库而言，这个是致命的，是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。
既然涉及到了中间件，那必然需要对消息丢失，重复消息的问题做预防处理，比如手动ack提交和保持消费幂等性
异步处理：
秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式，比如我将抢红包与发红包的逻辑拆分开来，发红包这种相对复杂的逻辑使用异步的方法滞后解决，简化复杂的逻辑。
读写分离：
读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库，我们的redis就可以这样设计，但是这里就需要考虑分布式的一致性了
降级预案
降级服务预案分析，提升系统的鲁棒性，
使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。
参考