利用消息队列
在一些对数据实时性要求不高的场景下，完全可以考虑在业务方和Elasticsearch中加入一个消息队列。可以抓住关键字 削峰和限流来回答。
之前优化过我们业务的架构，在数据同步到Elasticsearch之前，加入一个消息队列来削峰。在早期的时候，我们都是双写，一方面写数据库，一方面写Elasticsearch，在业务高峰期，Elasticsearch就会有性能瓶颈。
而实际上，我们业务对实时性的要求不高，在这种情况下，引入了消息队列。业务方只是写入数据库就返回，监听binlog并生成消息丢到kafka上。在这种情况下，如果Elasticsearch空闲的话，消费速率就高；如果Elasticsearch性能比较差，消费就比较慢，这样起到削峰和限流的效果
在这个架构的基础上，还可以考虑引入降级，也就是在 Elasticsearch 真的有性能问题的时候，关闭一部分消费者。
在这个架构的基础上，还做了一个简单的降级。如果有两类消费者写入数据到Elasticsearch，一类是核心数据消费者，一类是非核心数据消费者。
如果我监控到Elasticsearch性能已经比较差了，比如说写入的时候会遇到超时问题，就会把非核心数据消费者停下来。等Elasticsearch恢复过来再启动。
如果在大促或秒杀这种活动中，可以把整个数据同步都停掉，让Elasticsearch只支持查询操作。如果业务是电商类的，可以考虑这个策略。
