「高并发理解」
高并发意味着QPS很高，常见的有活动投票、低价抢购、直播间弹幕等等场景，取决于业务流量大小。 类似低价抢购，是有真实的下单数据写入，是一个写的高并发场景，对应也有只读的高并发场景。 「读」和「写」的高并发区别很大，读一般我们加多级缓存就可以，写往往会复杂些，需要考虑对应的场景。
「读高并发」
读高并发，一般可以用缓存来解决，一层缓存不够那就多层。缓存看重的是读取性能好，类似redis内存存储，速度就很快。
有了缓存，务必要考虑缓存的数据一致性、缓存穿透、缓存雪崩的问题。 一致性问题，无论是先删缓存，还是先写数据库，还是缓存双删都有不一致的可能，只能去降低概率，或加上定时job做异步补偿更新。 缓存穿透、雪崩，本质是增加缓存的命中率，减少DB的依赖调用。缓存时间错峰，热点数据不过期，提前预热缓存，缓存数据更新单线程阻塞执行，加布隆过滤器降低未命中缓存的再次查询。 现在往往也会在容器上做本地缓存，基于LRU、LFU等缓存淘汰策略，减少IO操作直接获取本地缓存数据，也是一个常见的方案，尤其是更新不太频繁的数据。
往往业务读高并发是有预见的，除了多级缓存，提前的业务域规划也很有必要，隔离出热点数据、热点服务，单独部署、保障横向扩展能力，在技术架构上做设计。 极端情况也会遇到突然一个热点数据冒出来，这就需要有一个兜底的热点探测器，识别数据的并发量，及时增加一层本地缓存提高热点并发能力。
「写高并发」
类似抢购秒杀业务，写高并发会有真实的数据库写入。这就有下面几个选择：
- 直接写，还是异步写
- 缓存写，还是数据库写 异步写，会有写的延迟，如果延后100ms或1s业务可以接受是一个选择方案。引入中间层的消息队列组件，也会提高对DB的写保护，是一个缓冲器。但也会带来另外一个堆积问题。需要有提前的消息堆积告警，及时的扩容提高消费能力。 缓存写，这时就会和DB的数据存在不一致的情况，取决于读场景是否也依赖于缓存读，类似点赞的场景，可能存在用户反复点赞和取消点赞，这时用缓存做一层数据存储载体是比较合适的，异步把缓存数据写入到DB中。
如果写高并发和读高并发是一起发生的，也可以采用CQRS的架构，把读写做服务和数据层面的隔离，增强读、写各自的稳定性。
「最重要的是可用」
线上总是会有预期外的情况发生，例如有刷子不断的请求不同的数据，直接伪造出了高QPS的情况，措不及防。这时候服务可用是最重要的，这个场景可以限流，特殊IP来源、请求uid来源进行限流措施。 如果是内部服务也可以对特定来源的appid做限流，确保其他业务方的可用性。
如果下游服务出现了问题，也可以对关键路径做降级预案，确保本服务的可用。高并发下先存数据，丢消息队列，或直接切换到备选的业务逻辑，依托于具体的业务场景来应对。
从基架层面，如果有一个服务出问题了，必要的熔断措施拦截掉该服务的调用，确保在高并发下该服务修复后可以重新站起来。
「流程建设」
技术方案review - code review - 预发验收 - 灰度观察 - 上线完成，高并发服务迭代尤其要严格走这个流程，及时是小的改动也要确认流程各个环节的无误。 其中灰度的节奏一定要慢，配合全套的日志监控，及时发现服务错误、业务同环比的数据差异，即使有问题也可以快速止损。
