可用性及稳定性保障主要是针对我们的大促活动而言，如何在承接亿级流量的同时保证系统的可用及稳定。这样的保障不仅是在技术上的保障，也需要流程上的保障。
整体挑战
应对流程
技术优化
缓存篇
- 活动库存使用缓存
加快扣库存操作，通过分布式任务异步刷入数据库（数据最终一致）
- 活动规则两级缓存
活动规则对象复杂，每次从redis读取时不仅会对IO造成一定的压力，在反序列化上也会增加CPU负载，通过本地一分钟缓存，降低IO耗时及CPU负载。规则的超时时间也设定在活动整体有效时间，规则有变动则会更新缓存，这样就不需要在读取的时候访问数据库。
- 领券记录缓存
主要是防止用户重复访问活动页，直接返回用户已领券的记录给到用户。
- 缓存失效时间梳理
失效时间的处理很有考究，既要考虑到集群的容量，也要考虑到用户场景，失效时间太长，对集群容量有压力，失效时间太短对数据库有压力。最好是在用户进入场景到离开场景的时间内保持缓存数据可用。
- 命中率（暂未有优化）
独立数据库
- 活动数据库集群单独部署
一主两从，两从分别在桂桥机房和南汇机房，在读的场景下避免跨机房读从库。
- 慢SQL优化
这里的教训特别大，第一次2亿流量直接导致数据库不可用，原因在扣库存的活动表没有索引，当时的活动不超过100条，相关开发人员觉得没有必要加索引，在小流量的场景下倒是没有问题，在流量大的情况下会引起激烈的GAP锁竞争。
服务配置优化
- 线程池优化
点评内部的服务框架是pigeon，比较和dubbo类似，框架默认会有大小为50的慢服务线程池，服务在一定的时间内处理时间超过阈值就会落入到慢线程池，实践证明慢线程池在很多场景下反而加剧了调用方调用超时。比如缓存或者第三方服务在压力比较大时，提供的服务会超出慢线程池定的阈值，这样可能会导致所有的请求都会落到慢线程池（尤其是缓存访问变慢的场景）
固定线程池大小，coreSize和maxSize大小保持一致，设定在200，减少线程池回收及创建时间。（因大部分服务都服务IO密集型，线程数可根据压测结果适当调大）
合理配置队列大小 目前是拍了脑袋定在了400，目的是提高服务的吞吐量。合理性待考究。
超时时间梳理
超时时间的梳理主要是解决物尽其用的场景，怎么在有限的服务资源下提高系统的可用性。
超时设定分为服务超时以及http的so_timeout，超时的设定会在极端情况下反应出你的系统的极端负载，打个比方，一个查询接口的SLA：avg在200ms,可承受1000的qps，一旦这个服务出现故障，导致avg升到了400ms，部分请求时长超过了2s，如果你的超时时间设定在了2s，那将会出现很多线程被超过2s或者即将到达2s的请求占用，用于其他正常请求无法获得处理线程，最终会导致你的服务性能急剧下降。
在者考虑到调用端的性能，服务的超时时间设定的太长会使增加整个调用链路时间，不仅降低用户体验，还会占用调用端的线程资源。
如何确定超时时间？实践是999线加上avg，大部分场景都会覆盖到，如果服务的稳定性不是很高，可适当加上avg的倍数。
为什么选用999线？选取999线的话可使可用性达到三个9。
为什么还要加上avg? 三个9的可用性这个要求其实对服务的要求并不高，还需要加上一定的时长能够使服务达到4个9或者更高。然而这个一定的时长我们不能拍脑袋，例如一个服务他的avg为100ms，999线为200毫秒，我们拍个脑袋，超时时间设定在了2s，显然2s设定太过高。当然在服务的资源很充分的情况下你可以不用去考虑这个超时时间，我们是在讨论如何在有限的资源下提高系统可用性。avg是个参考值，大部分人在设定超时时间的时候会考虑到以秒为单位，但是很多服务的avg都不到50ms，显然设定在2秒肯定是不合理的，这就需要avg这个考虑值。
future并发调用
future并发调用一般运用在调用方，如果一个请求里面有多个服务调用，部分服务之间并没有关联，尤其对外提供聚合服务的时候，很多服务是没有调用顺序的，这种场景最适合使用future并发调用，使用并发调用的话，一个请求里的多个服务调用时间并不是相加，而是变成了耗时最长的单个服务时间。这样大大的提高了响应时间。
MQ优化
美团点评内部提供RabbitMQ和Mafka(kafka封装)两种类型的MQ，基于营销场景的使用情况（时效性要求不高，吞吐量大，可容忍消息丢失），最终选择了Mafka。（订单场景下慎选）
- 同机房策略
MQ的集群和应用同机房，应用如果北京上海都有部署，那mq的集群也需要两地部署。这样应用产生的消息发送到同机房的mq，避免专线的耗时带来吞吐性能下降。这样也要求消费机也在相同机房有部署，将专线影响降到0。
- 消息异步发送
同步主要会带来一个mafka内部一锁的竞争，而且一次是单个消息发送，在IO利用率上不是很好。异步发送的话一是无锁，二是可全并消息批量发送。 - 增加集群分片及消息者
mafka的一个分片只能一个消费线程消费，如果分片过少，那就制约了消费线程数。在消息有堆积的情况下可适当增加分片以及消费线程，提高消费能力。
