1. 你是怎么看待异地多活的重要性的？
异地多活是重要系统的标配啊，“两地三中心”，“异地多活”你值得拥有。
不过这个具体的实现就要看系统规模及使用者的情况了。如果是大型集团的大型系统可以自建，如果是小公司和小应用可以选择具备这种能力的云服务，比如阿里云。其实即使对于大公司，把自己的私有云和阿里云等公有云组成混合云也是一个很好的尝试，用好了也可以提高系统抗击风险的能力。

2. O2O架构究竟应该如何设计？
O2O作为一个2C的平台，具有流量较大，而且随着活动会有爆发性的增长，另外还要考虑恶意的攻击和羊毛党。所以对系统的并发能力，稳定性，安全性等等要求都相对比较高，所以服务化，读写分离，分库分表，纵向拆分，横向拆分，应用缓存，限流保护，网络安全等等这些都是要考虑的。

3. 应当如何做好极端事件的快速恢复？
首先是数据，只要数据还在一切都好说，数据没了就是真的完蛋了。即使数据能恢复，解决起来也通常比其他的问题要麻烦。还有一点就是在应急起系统的时候一定要注意不要把数据的一致性搞坏了，否则过后会很麻烦。
其次就是看你事先的准备情况了，如果你以前有准备而且有经过验证的预案，那么就按照预案来执行好了。在做预案的时候要经过充分的论证，不能想当然，比如挖掘机把你主机房的对外的线缆都挖断了，你如果直接把这部分流量直接导到其他机房，它不一定能扛得住，这时候你可能就需要限流了。
如果事先没考虑，没准备，那么就只能临场发挥，自求多福了。

4. 没外卖订了你会怎么办？吃不饱怎不办？（option）
自己做呗，呵呵，给家人做一顿好吃的，他们Happy的吃的时候，你会觉得很快乐的。

可以的话，给个笔记本吧。

1. 你是怎么看待异地多活的重要性的？
   这就是两地三中心的重要性了，本地挂了，异地迅速开启业务。如果没有做好备灾演练，异地多活存在不确定性，很可能无法恢复业务。
2. O2O架构究竟应该如何设计？
   逐层解耦，日常监控分析，支付数据做好回滚操作，确保数据准确性，遇到问题迅速加锁数据库，使支付无法使用，可以保证业务的正常有序和安全性。
3. 应当如何做好极端事件的快速恢复？
   做好备灾演练，同时保证异地两台服务器的活力，形成环路保护，平时做好相互保护即可。
4. 没外卖订了你会怎么办？吃不饱怎不办？（option）
   自己煮呀！总不能吃键盘吧

1. 你是怎么看待异地多活的重要性的？
平时不出事，看不出重要性，一旦出事，就非常重要了。

2. O2O架构究竟应该如何设计？
水平垂直都要做，分层，业务解耦。
以及完整的日志体系，数据流转跟踪，监控等。

3. 应当如何做好极端事件的快速恢复？
轮岗制，24小时相应。
定期线上模拟，针对重要业务明确预案细节。

4. 没外卖订了你会怎么办？吃不饱怎不办？（option）
一直做饭，做饭也是一种创造，我觉得会做饭的程序员才是一个好厨子！

群众的外卖问题从来都不是小问题，吃不饱怎么能更好的发挥生产力呢！就让我们来聊一聊：

1. 你是怎么看待异地多活的重要性的？
   异地双（多）活。而异地双（多）活，却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。

跨机房的流量是花钱的。所以不是无限大的。控制跨机房消息体大小，越小越好。然而，很多时候要想保证数据同步是一件很耗费流量的事情。但跨机房流量真的是一座山。

1. O2O架构究竟应该如何设计？
   同城灾备，异地备份。现在行业主流的两地三中心建设。
2. 应当如何做好极端事件的快速恢复？
   如果机器资源不足，建议优先将一些体系独立的服务整体迁移，这样可以为核心服务节省出大量的机架资源。如果这样之后，机架资源仍然不足，再做异地多活部署。

谨慎挑选第二机房：尽量挑选离主机房较近（网络延时在10ms以内）且专线质量好的机房做第二中心。这样大多数的小服务依赖问题都可以简化掉，可以集中精力处理核心业务的异地多活问题。同时，专线的成本占比也比较小。
注意机房间的延时问题，延时大的可能达到100ms以上，如果业务需要多次跨机房请求应用的话，延迟的问题会彻底放大；
跨机房的专线很大概率会出问题，要做好运维或者程序层面的容错；不能依赖MySQL双写，必须有适应自身业务的跨机房消息同步方案；

1. 没外卖订了你会怎么办？吃不饱怎不办？（option）
   这个要求充足的备货，攻城狮必备：方便面、老干妈。。。。。。。。。。。

希望一个鼠标垫！

哈哈，占个楼先

1. 你是怎么看待异地多活的重要性的？
   异地多活其实是不太理解了，字面理解，分布式架构的一种吧
2. O2O架构究竟应该如何设计？
   这个感觉问的深了，多个集群咯
3. 应当如何做好极端事件的快速恢复？
   回滚，最先想到的反应，应该大公司都有plan b吧 ，同样一份服务替换上
4. 没外卖订了你会怎么办？吃不饱怎不办？（option）
   公司吃呀，so easy

哈哈，求笔记本一枚

鼠标垫～鼠标垫～鼠标垫～

1. 你是怎么看待异地多活的重要性的？
   区域网络出问题还是比较常见的，只是很多企业都做了异地多活，所以我们平时并没有感觉出来。越大的企业，受众也越大，影响也越大。所以如果大企业没有做好异地多活的话，我们马上就能感觉到，比如这次的美团（此处指感觉到，不是说他们没做好异地多活）。但是这次美团事件，我觉得并不是异地多活没做好，应该是其他方面的原因。现在的技术架构下，已经很难因为一个区域的机房挂了，导致用户无法正常使用了。像段子里的这2种情况都是早年才会发生了，说明段子手并没有与时俱进。
2. O2O架构究竟应该如何设计？
   O2O最大的特点应该是分布式，或者说跟物联网的雾计算有点相似。每个地区都有自己的计算和网络中心，信息就近处理反馈，才能有最好的体验，同时也大幅降低了网络压力。同时结合异地多活。本地挂了，马上无缝启动异地灾备。
3. 应当如何做好极端事件的快速恢复？
   技术是一方面，公关也是一方面。出现极端事件，宣传部门要第一时间做出反应。不隐瞒，不搪塞。公众就会安心等结果，不然就会各渠道跟着一起瘫痪。
4. 没外卖订了你会怎么办？吃不饱怎不办？（option）
   下楼走上十几米，还有几家小面馆。家里也做了灾备和异地多活。有面包、零食、泡面、米、矿泉水、大量饮料等等，真饿不到。

这个事情好像就是前两天的事情吧，我们授权服务中同事还在说，美团该换服务器了，全部换成阿里云的，就不会出现这样的问题了，不过阿里确实可以做一套解决方案供美团高层参考一下了

666666666666

666666666666666666666666666666666