每一篇都值得精读，重复读

耗子哥觉得 Kong 这个API Gateway如何？

水平有限这节没完全理解，记一笔，后面再看几遍

耗子哥，一个服务号有1亿的关注关系，我们有5个类似的服务号，也就是有约5亿的关注关系，我们都存在一张表里了，这张表只做了分区。发送1亿条消息时，我们会反复的查这张表，所以这就是瓶颈，我打算把这张表的数据都存到redis里，分成多个list存，类似表的分区，发时多个线程并行发送，每个线程负责一个redis的list，这样设计可以吗，耗子哥？

耗子哥，请教个问题，我在做一个类似微信的app，公司有个需求，要求1亿条消息在5分钟内发送到用户，现系统1亿条消息大概需要1小时才能都发给用户，您能提示我一些优化方向吗，谢谢

阿里不是还有个rocketmq用来做分布式事务么，这个怎样呢

在 IaaS 层上解决这个问题，一般来说有三种方案，一种是使用比较廉价的开源产品，如：NFS、Ceph、TiDB、CockroachDB、ElasticSearch、InfluxDB、MySQL Cluster 和 Redis Cluster 之类的；另一种是用云计算厂商的方案。

耗子哥，这些应该是paas层吧

耗子哥，我想咨询个问题:以前你在微信朋友圈发过一个治疗痛风的药:GPro,效果如何？

收获很大，帮助将自己的很多知识点进行了系统化的梳理，理解更加清晰和深刻，非常感谢！

另外，megaease的“联系我们”部分有语病：这样能才提供最好的服务和支持。

“然后拼命地使用各种 tricky 的方式来提高 latency”
我理解是降低latency吧

smasMegaEase.com 这个地址访问不了

流量调度的功能在于可以自动扩展调度流量，可以应对突发情况，需要做服务流量调度，流量控制。
流量调度的关键性能要保证高性能，扛流量，可编程，服务化。
同时流量调度存在状态数据调度的问题，应该在iaas层解决有状态数据的问题

流量控制，采用api gateway

数据的分布式一致性和事务，应由数据组件自己负责，而不是在业务中，分库分表，这些思想体现在让功能分离，专业的组件做专业的事，从而才能那个不同的组件够精简，同时把自己关注的事情发挥到极致。

这块之前没有涉及太多，部分需要再消化

tidb和mysql cluster，请教，这2种比较，如何?

为什么paxos不可以用在应用层呢？是因为数据层主要是副本一致性，比较适合paxos么？

真正解决数据状态调度，其实就是有一个分布式且支持事务的数据库，突然想到最近新起的newsql数据库不就是为了解决这个问题而来的。

API网关，分布式技术。这篇文章里提到应用层两段提交的方案以及分布式存储。从技术上讲，无状态服务在分布式中可以比较顺利地扩展，但无状态说明状态存在了其他地方，比如数据库或者本地文件。但数据库的数据复制和同步本身也是一个复杂的问题。如果能从底层文件系统出发直接实现底层文件系统就是分布式的，那么在数据同步方面会更简单。

请问大哥：这篇文章发布在两年前，国内外各家大厂的技术也在进化。请问两年前您下的一些判断，现在是否有什么变化？有什么更新？“成熟的可以用到生产线上的分布式数据库这个事估计也不远了”，这个现在有了吗？