单机故障重启，这个没有说服力，故障是肯定有原因的，应该找到根本原因.故障重启不是一个资深工程师的解决问题的方法.强烈不认同

只能通过最终一致性保证，比如MySQL的binlog复制

"系统能够承载的流量根据集群规模的大小是固定的，可以称之为系统的最大容量"
请问这里的"系统" , 是指整个微服务应用, 还是指单个服务器?
联系上下文看了,还是不能准确的判断作者指的是哪个..

嘿嘿😁，每逢大促，应急预案演练RPC这块也讲这些，确实不够深入，不过也能理解毕竟篇幅有限，深入还行看书。
感谢!

一般不保证实时一致性，只能保证最终一致性。
1、两个中心中拉专线，进行数据底层同步。2、对于重要数据在做完底层同步后还可以通过消息队列再做一次异步同步来作为补偿。但是要控制好，防止数据重复写入。

一致性分为弱一致性和强一致性。强一致性比如银行转账业务，就必须要求是强一致性。而对于微博评论，并不要求发出去之后立马看到，只要最终看到就可以，晚一点也没关系。
对于强一致性系统，一般都会有读写分离，读可以从多个备份中取数据，而写必须要数据同步到所有备份之后返回。
而弱一致性性，读写分离之后，写的话只写入主库就可以直接返回，然后异步同步到其它备份。这样就会出现某些请求拿不到最新数据

拉光纤专线能否实现？但是数据完全一致似乎很难做到？

单机故障，重启过于暴力，硬件问题出现ping不可达，假死可以重启，其他软件层面还是要有其他层面的分析

能讲一下限流和降级具体怎么做么？现在只是理论。

监控要到位，包括硬件及服务。根据收到的告警内容综合评估吧，可能是流量太大导致单机处理瓶颈。可能是物理机挂了导致的硬件故障。直接重启有点暴力。但最终大都离不开，重启，回滚，加机器。

现实中网络不可靠是一定的，所以，CAP理论中的P（分区容忍）一定会出现。所以，CAP理论告诉我们实现情况，我们只能够在CP和AP之间进行选择。

最大线线程数设置多少合理？我们高峰期有10000多，当然服务现在还没拆！这样8核16G都跑不满

线程数达到多少算瓶颈？我们高峰期现在是10000多，8核16G！cpu都跑不满

负载均衡中健康检测可以应对单机故障的情况

用九桥，在异地机房在数据实时备份

能否讲讲具体的限流方法，例如有接入层限流，nginx的配置等

分布式数据库，通过分布式锁控制数据写入和更新删除。

异步不复制，最终一致性即可

如果没有很大实时性需求的话，两个idc之间保持后台数据同步，故障恢复后等数据同步完成再开启关闭的idc。