04 | 系统设计目标（二）：系统怎样做到高可用？

感谢老师的分享，对于文章中的心跳检测我个人认为其实是需要做区分的，心跳检测是区分内部检测和外部检测，外部检测伴随着随机性，有时候可能系统的响应时间或者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理论，这样对于基础知识欠缺的人，在学习的时候也可以去补一些平时没有刻意学习的知识，上面是我举的例子，再次谢谢老师的分享，期待后面老师的干货文章。

高可用思路， 1.开发设计层面 冗余---主备，负载均衡，failover 取舍----降级，限流，熔断，超时控制 2.运维层面 灰度发布，故障演练，监控报警

我觉得思想最重要，光教你们具体的人家用过的实际案例，那不过是画饼充饥，每个公司的业务都完全不同，侧重点也不同，掌握了思想，明白了了设计方案和要注意的点，接下来只不过是考验个人思维严谨程度和代码水平，思想大于奇淫技巧

1.本篇讲得主要是系统设计层面的服务高可用。降级，限流，超时熔断，好像主要大方向就这些了。（走mq销峰这种，我认为也是一种降级）。 2.从运维来看，上k8s后，编排控制下，自动维护运行的服务实例节点数量算（包括无状态和有状态服务），这算是一个高可用方面的方案。 3.从部署架构来看，单机房的集群，主备，redis es的多副本等等也算。扯远点还有同城异地，异城异地以及搭建灾备中心等高成本操作。（主要看系统不可用带来的损失有多大，进而做决定）。 总之工作中，感觉追求系统高可用比追求高性能难太多。

希望老师能带来大家一步步设计出一个系统，从简单到复杂，演化出一个高并发、高可用、高性能、可扩展的系统。可以模拟遇到具体的问题，使用什么方法去解决。

老师您好，我们产品中用到了MongoDB自带的集群来达到高可用性，但发现当某个节点出现故障时，MongoDB大多数时候并不能自我恢复，从而极大影响了用户体验。对于这种案例，老师有什么好的建议?

网络跟交通真是很像 限流：对应交通中的限号； 降级：比如火车的站票，人太多，坐座没有了，改为站票，但票价没变，这就是有损服务啊 故障转移：轿车上一般都准备一个备胎。有些人找对象时，也会准备一个备胎，以防主胎出问题了，还可以更换。

希望老师能带来大家一步步设计出一个系统，从简单到复杂，演化出一个高并发、高可用、高性能、可扩展的系统。可以模拟遇到具体的问题，具体使用什么方法、使用哪些工具去解决。

讲的思路很清楚，虽然以前也知道高性能高可用，但没看过这么全面的总结。

RPC是什么？是一个调用远程接口的工具，还是一个什么框架？