今天听朋友说起一个需求：40万每秒写请求，应该怎样设计架构？
    40万每秒，单机情况下应该没有什么单机数据库能够支持吧，针对单机支持情况，网上搜到下面资料

    • MySQL：10w/s - 15w/s
    • Redis：支持读11w/s，写8w/s
    • ActiveMQ：万级吞吐
    • RabbitMQ：万级吞吐
    • RocketMQ：10万级吞吐
    • Kafka：10万级吞吐
    • ES：网上大概说是几千到一万每秒写
    • Mongodb：1万左右

    这么看来单机肯定支持不了。那么要怎样处理呢？我觉得应该按照以下思路：

    • 1、这40万每秒的数据，是不是都是关键数据？可不可以丢弃一些重复数据？或者按照一定规律，合并数据后再插入？数据会不会定期删除？保存周期多久？（40w/s，一天会产生345亿条数据）
    • 2、存储数据：可以选择MySQL分库分表或者ES集群，或者一些NoSQL数据库
      • ES不熟悉就不说了
      • MySQL分库分表，可以解决写压力，和存储压力（这么大的数据量基本放弃MySQL了）
      • Mongodb，分片集群，同样可以解决写压力和存储压力
    • 3、限流。这么大的数据量，一下子冲击过来，肯定会压跨下游的服务的。所以如果是从http获取的数据，先存在MQ中，再慢慢消费，根据队列的情况再布署消费者。
    • 4、上游压缩。如果上游是40w生产者，消息就很难压缩了。如果上游是400个消费者呢？生产的消息是不是有一定的规律？能不能压缩？如果能压缩的话，也减轻了服务器的带宽压力。
    • 5、存储的数据，是不是要进行搜索？建议考虑ES