作者回复: DBWriter可以和Aggregator做在一起，这样的确简单。但是这样也有问题，一个是Aggregator的逻辑会搞复杂(又要计算又要写DB)，第二个是DBWriter和Aggregator就耦合了，后续升级更新就要一起更新，不能单独更新DBWriter或者Aggregator。

作者回复: counting和query service都是无状态，可以部署多台做成集群，一般假定不会全部挂。 缓存有很多HA技术，比方说redis支持主从+哨兵，还有cluster集群等，一般也假定不会挂。当然，redis是可以开启持久化的。

作者回复: 对，如果要对冷数据进行查询处理，肯定需要对查询服务做一些包装和扩展的。一般像阿里云oss，AWS S3等，都是有API可以调用的，基于这些API实现查询也不是很复杂，只要合理设计文件的存储结构。 比方说像prometheus之类的时间序列数据库，就支持所谓远程存储，可以参考thanos(https://thanos.io/)项目，它支持GCP, S3, Azure, Swift and Tencent COS等作为promethues的远程存储，相当于冷存储。

作者回复: 我之前就曾开发和开源过一个持久化的queue https://github.com/bulldog2011/bigqueue 另外，你基于磁盘文件，自己实现一个持久化的queue，也不麻烦。 还有，用嵌入式DB，比如sqlite/berkeleyDB等，也可以实现简单queue的功能。

作者回复: 一条一条消息发，和聚合一段时间再批量发，性能有数量级的差异。请继续看第三章消息队列的设计，里头有专门讲到这个问题。

作者回复: 我之前公司主要采用CAT进行应用性能监控，CAT是支持JVM监控的，还支持线程监控。另外，Skywalking也是支持JVM监控的。 https://github.com/dianping/cat https://github.com/apache/skywalking

作者回复: 1. MQ的分区，比方说Kafka的分区，是直接支持高可用的。对于每一个分区，Kafka支持在不同Broker节点上复制多分数据拷贝。 2. Consumer端的第二个缓冲队列，是需要考虑持久化的，这样数据才不会丢。当然内部队列都要监控，如果超过一定大小要告警。