2018-07-03oceanbase的强一致分布式数据库可以使业务不需要考虑持久层的跨地域数据同步问题。
但应该付出的代价是单个请求的rt会变大，可用性也有降低，所以对rt要求非常高的业务可能不会选择，其实还是对业务有影响的。
如果代价可以承受，业务端还要解决缓存的一致性问题，流量切到其它可用区的压力是不是承受的住。可能还是需要部分业务降级。
所以分布式数据库不能完全做到业务无感知的异地多活作者回复: 分析正确，异地多活并不是单单持久层考虑就够了
27
2018-07-03强烈建议老师能够多给一些准备文章所查找的资料链接，毕竟文章属于高度总结概括的，老师只是领进门，吸收知识还是靠自己去看，去领悟作者回复: 如果是异地多活，理论只有CAP，网上有很多实践案例，但都没有提炼通用方法论，专栏的异地多活内容基本都是我自己悟出来的😊
如果是其它章节，文章内容已经包含关键部分，细节你可以拿其中的关键字去搜索 6
2018-07-03oceanbase采用了两阶段提交来实现跨区多机分布式事务。当协调器出现故障时，其通过查询所有参与者的状态来恢复分布式事务。当某个分区故障或网络中断时，事务会长时间挂起，直到故障修复，这段时间内部分其实是不可用的。虽然其声称强一致性和高可用，当发生故障和网络中断，依然会导致服务不可用。 5
2018-12-26假如有多个应用 而不是ab2个 那么当前处理不了请求对端 那么是要请求哪端呢
session也是同样例子。因为不知道session是哪个应用生成的 是不是session上要带ip信息 做反向连接用作者回复: 是的，session设计要考虑识别来源
3
2018-08-08有几个疑问，请问A和B两个城市机房，
1.假如在A改了密码，在B是不是有可以通过旧密码登陆的可能呢？
2.以此类推，假如是存款金额，怎么判断B的数据是最新的呢？
3.银行转账通过申请的方式，需要所有城市节点反馈，才确定扣款吗？
4.银行转账通过申请的方式，如果其中一个城市宕机了，是不是所有城市都无法扣款呢作者回复: 1. 有，我自己都遇到过QQ密码和淘宝密码不同步的问题，当然是十几年都各自只有一次
2. 没法判断，余额只能做只读备份，不能双活，除非底层存储是基于paxos做的分布式一致性，但理论上paxos的分布式系统也会整体挂掉，因为目前的技术，节点间连接的问题是解决不了的，除非量子通信😄
3. 不会，两个账户所在的节点正常就可以了
4. 不会，只是这个城市的用户没法扣款，其它城市的用户不受影响 1 3
2018-07-12qq的账户登陆这一块应该就是做了多机房回源读取。因为他们的业务就是密码错误，会让用户输入验证，我估计应该至少有这两个功能：1、人机校验；2、留充足时间给多地机房数据确认；作者回复: 这个我还真不知道，不过你这样分析也有一定道理
3
2018-07-04你好，华哥。请问能否在后续也指导下日志系统的知识，微服务框架下的日志选型？谢谢了。作者回复: 我的专栏目的在于教会读者架构分析和设计方法论，而不是具体某个系统如何实现，你可以参考架构设计选择，架构设计流程等知识自己实践一下
2
2018-07-03在注册里，如果A中心宕机，消息队列因为处理时延未到B中心，二次读取因为A中心未恢复也失败，这种情况有什么好的处理建议？作者回复: 没法处理😄只能让部分用户受损
2
2018-07-03想请教一下华仔，在真正的应用场景中，使用消息队列异步推送的可靠性高不高？NServiceBus消息队列在真正项目中的运用还可以吗？ 2
2019-02-13使用了这么多同步方式看上去是依不同情况做的不同处理，但是在一个服务里用这么多不同的方案会加大后续的维护成本吧，人员理解都要花一些时间，出问题了排查方式还不一样作者回复: 首先要解决业务问题
1
2018-12-01您好，问一下文中说不能以后一个手机号注册为准，这个原因是什么呢？注册是可以有时间记录，在做高可用切换时以最后一次注册时间为准不是蛮好的解决方案吗？还请赐教作者回复: 因为用户注册后可能执行很多操作
1- 2018-07-03oceanbase采用了两阶段提交来实现跨区多机分布式事务。当协调器出现故障时，其通过查询所有参与者的状态来恢复分布式事务。当某个分区故障或网络中断时，事务会长时间挂起，直到故障修复，这段时间内部分其实是不可用的。虽然其声称强一致性和高可用，当发生故障和网络中断，依然会导致服务不可用。 1
- 2020-01-01请教老师一个问题：通过多种途径复制信息有一个复杂度较高的问题，就是不同信息复制的先后顺序安排造成关联数据的先后入库问题，如通过消息队列复制新创建账号信息，通过数据库复制账号密码。如果数据库先发起，消息队列消息后到，这就会出错，因为还没有这个账号。所以，多个渠道复制，复杂度过高，是否真的适用？
作者回复: 没有普遍适应的复制方法，你说的这个场景就不要用，但对于一些尾部追加的数据就可以用
2019-12-20单持久层强一致只解决一部分问题。应用层的问题还没有解决。如果北京的应用层过载或断电，上海应用层就要承担更多任务
2019-09-18首先为应对自然灾害保重证高可用，oceanbase集群必须跨城分区，那么如下两个问题就不可避免:一是跨城分区带来的时延问题会导致集群对某次写入达成一致的时间变长出现数据不一致;二是成本问题，为保证跨城分区之间网络的可靠性可能要考虑公网和内网共存，部署成本上升。
再说当发生故障时如果恰好是[n/2+1]个节点所在的分区发生故障，那么整个集群将由于无法达成多数派而停服。
最后一点，paxos协议的使用场景通常是读多写少，写操作会存在瓶颈，集群的规模不会很大。作者回复: 赞同
2019-08-31课后思考及问题
1：听完的第一感觉是系统理论上100%高可用是不可能的，不管是双机架构还是高可用集群架构甚至是最牛逼的异地多活架构都无法保证100%高可用，因为进程间通信协作是需要网络通信的，而网络通信的环境是复杂多变的不能100%安全可靠，另外，数据延迟是无法避免的，那数据实时一致性是无法做到的。世间没有完美之事，当然，这并不表示这样的人生不值得过活，这恰恰是我们奋斗的目标和动力。我们接受不能100%高可用，但是我们要保证核心业务高可用，并且大部分业务高可用，其实实际情况也是如此的，系统不可用的是小概率事件。
抓住主要矛盾的主要方面，基本就能做的立于不败之地。
2：如果底层存储采用 OceanBase 这种分布式强一致性的数据存储系统，是否就可以做到和业务无关的异地多活？
OceanBase没用过，不过根据软件编程没有银弹以及天下没有免费的午餐来推断，应该做不到和业务无关的异地多活。异地多活有一定的业务适用范围，也不仅仅只是解决分布式数据存储的问题。
如果是金融业务，要求低延时，还包括一些计算业务，也许就不太适合啦!情愿牺牲一下系统的可用性牺牲一下用户的使用体验，也要保证业务的逻辑一致性。展开
2019-08-10有个想法：对应异地多活不可能100%实现的是，人的感官也不是完全连续的，这首先帮我们排除了毫秒级异地多活的需求。
其次，秒级的连续性可以用交互界面搭建，如课程所讲。
如果场景允许，更长时间的连续性可以显示声明事务阶段，例如文中的的转账申请。这利用到了设计理念中的示能概念，就是利用人对申请是个流程的自发认识。
总之，我的看法是架构不应该向功能回归，而是要向业务目的回归。作者回复: 前面说的挺好，最后一句没看懂呢
2019-05-13通过消息队列同步数据，与数据库同步数据，两者逻辑上如何配合？
是前者作为后者的补充协调方案，还是在发现数据库同步有问题的时候，主动走消息队列通道？
还有消息队列同步理论上是不是也会碰到网络抖动、延迟等等问题作者回复: 你分析的都对，具体实践要结合业务进行取舍
2018-09-18这里的归纳完善后逻辑应该是：根据经济能力、所需时间及业务要求有先后地选择异地多活的业务及业务多活的形式。作者回复: 赞👍
2018-09-06为啥会出现用户在A中心登录，又在B中心登录的情况？不是会选择最近的中心吗，只有A中心故障才会去选择B中心登录？作者回复: 你坐高铁，或者处在两省交界，或者一会用无线，一会用4G，甚至路由出bug……很多情况的😀