昨天中午我室友饥寒交迫的从外面,回到寝室就想很一口热乎的粥,然后高高兴兴的抢了一张某团粮票点了一份十块钱的粥就等着外卖小哥送来拯救自己了,然后的事情相比大家都知道了,支付成功了以后却没有反应了,然后就是迟迟等不到商家接受订单。
差不多是在中午 11 时左右,网友们纷纷发微博反应状况:
更是有不死心的小哥连续多次付款:
然不止美团,大众点评也如此,服务器出现大面积崩溃,App 的外卖、团购业务均受到影响。而后,据悉美团外卖的在线客服、电话客服疑似被“打爆”,系统繁忙无法接入。美团外卖的置顶微博评论区也“沦陷了”,网友纷纷吐槽付款/退款等问题。
然后各路抖机灵的段子手都开始纷纷出动了:
还有刚经历过碰壁的微博技术小哥的抖机灵:
虾米VIP月卡 x 2
云栖定制鼠标垫 x 2
定制笔记本 x 2
北方的郎
已获得定制笔记本
复制链接去分享
1. 你是怎么看待异地多活的重要性的?
异地多活是重要系统的标配啊,“两地三中心”,“异地多活”你值得拥有。
不过这个具体的实现就要看系统规模及使用者的情况了。如果是大型集团的大型系统可以自建,如果是小公司和小应用可以选择具备这种能力的云服务,比如阿里云。其实即使对于大公司,把自己的私有云和阿里云等公有云组成混合云也是一个很好的尝试,用好了也可以提高系统抗击风险的能力。
2. O2O架构究竟应该如何设计?
O2O作为一个2C的平台,具有流量较大,而且随着活动会有爆发性的增长,另外还要考虑恶意的攻击和羊毛党。所以对系统的并发能力,稳定性,安全性等等要求都相对比较高,所以服务化,读写分离,分库分表,纵向拆分,横向拆分,应用缓存,限流保护,网络安全等等这些都是要考虑的。
3. 应当如何做好极端事件的快速恢复?
首先是数据,只要数据还在一切都好说,数据没了就是真的完蛋了。即使数据能恢复,解决起来也通常比其他的问题要麻烦。还有一点就是在应急起系统的时候一定要注意不要把数据的一致性搞坏了,否则过后会很麻烦。
其次就是看你事先的准备情况了,如果你以前有准备而且有经过验证的预案,那么就按照预案来执行好了。在做预案的时候要经过充分的论证,不能想当然,比如挖掘机把你主机房的对外的线缆都挖断了,你如果直接把这部分流量直接导到其他机房,它不一定能扛得住,这时候你可能就需要限流了。
如果事先没考虑,没准备,那么就只能临场发挥,自求多福了。
4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
自己做呗,呵呵,给家人做一顿好吃的,他们Happy的吃的时候,你会觉得很快乐的。
可以的话,给个笔记本吧。
aoteman675
已获得虾米VIP月卡
复制链接去分享
夏之冰雪
已获得虾米VIP月卡
复制链接去分享
1. 你是怎么看待异地多活的重要性的?
平时不出事,看不出重要性,一旦出事,就非常重要了。
2. O2O架构究竟应该如何设计?
水平垂直都要做,分层,业务解耦。
以及完整的日志体系,数据流转跟踪,监控等。
3. 应当如何做好极端事件的快速恢复?
轮岗制,24小时相应。
定期线上模拟,针对重要业务明确预案细节。
4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
一直做饭,做饭也是一种创造,我觉得会做饭的程序员才是一个好厨子!
hikingx
已获得云栖定制鼠标垫
复制链接去分享
群众的外卖问题从来都不是小问题,吃不饱怎么能更好的发挥生产力呢!就让我们来聊一聊:
跨机房的流量是花钱的。所以不是无限大的。控制跨机房消息体大小,越小越好。然而,很多时候要想保证数据同步是一件很耗费流量的事情。但跨机房流量真的是一座山。
谨慎挑选第二机房:尽量挑选离主机房较近(网络延时在10ms以内)且专线质量好的机房做第二中心。这样大多数的小服务依赖问题都可以简化掉,可以集中精力处理核心业务的异地多活问题。同时,专线的成本占比也比较小。
注意机房间的延时问题,延时大的可能达到100ms以上,如果业务需要多次跨机房请求应用的话,延迟的问题会彻底放大;
跨机房的专线很大概率会出问题,要做好运维或者程序层面的容错;不能依赖MySQL双写,必须有适应自身业务的跨机房消息同步方案;
希望一个鼠标垫!
水灵儿
已获得定制笔记本
复制链接去分享
哈哈,占个楼先
哈哈,求笔记本一枚
浮生递归
已获得云栖定制鼠标垫
复制链接去分享
鼠标垫~鼠标垫~鼠标垫~
😊😊😊😊