感谢老师的分享，对于文章中的心跳检测我个人认为其实是需要做区分的，心跳检测是区分内部检测和外部检测，外部检测伴随着随机性，有时候可能系统的响应时间或者IO已经出现拐点了，但是心跳机制还是有可能会收到响应包，从而被错误的当做系统是“正常”的，所以很多高可用的系统基本都是采用内部心跳机制，比如kafka中的通过zookeeper的watch机制来做检测来做broker中controller的failover，mysql里面是通过内部的performance_schema库中的file_summary_by_event_name表来做监控，都是为了避免外部监测的随机性所带来的影响，不过对于老师提出的可用性和高性能当中出取舍无比赞同，不同的解决方案总是伴随着优势和劣势，无非是优势所带来的效果比劣势对业务更有帮助而已，比如之前在工作中碰到过mysql主从同步有延迟的情况，mysql的高可能性其实就是靠主备同步的数据一致性来保证的，经过排查发现，业务代码中存在有操作大事务的SQL语句，这个导致从库拿到binlog去做重放的时候，时间周期拖长了，从而影响了业务，另外一个情况就是，在做秒杀的时候，除了采用redis外，还会对用户划分成两部分，一部分用户是来了以后直接报秒杀已结束，另外一部分用户才会进入秒杀的逻辑中，心里觉得还是挺对不住那部分抢不到秒杀的用户的，所以，有时候我们需要在可用性和可靠性上需要做一个取舍，没有十全十美的技术解决方案。除此之外，其实大部分的时候采用的策略是需要对业务尽量是无损的，不然运营和产品会请你喝茶的，最后想跟老师提个建议，就是希望后面的一些篇章，能否尽量将之前提到过的知识点实际运用起来或者说串联起来，并且提供一些实际场景的解决方案细节，我举个例子，比如电商秒杀，秒杀如果只采用mysql去做库存判断，会出现什么的问题，为了避免这样的问题出现，该采用什么系统，假如如果采用redis，为什么？redis的一些操作是原子操作，原子操作是什么？如何保证？类似这样的方案的优缺点和延伸，这样的话既能有效的总结之前学习到的知识点，能够将整个知识网络做一个规整，还能了解到每个技术方案的不足加深理解，从而明白什么样的场景说不能采用当前的技术方案的，还有就是在采用技术方案的同时，说明下采用方案的一些基础的理论，知识，比如cas，或者分布式系统中的cap理论，这样对于基础知识欠缺的人，在学习的时候也可以去补一些平时没有刻意学习的知识，上面是我举的例子，再次谢谢老师的分享，期待后面老师的干货文章。