[构建高性能web站点]-2实际案例

        想不到早上写了读书笔记一,晚上就给我一个实例来完成读书笔记的第二集了。

        今天是举国哀悼日,国米比赛不转了,QQ农场也不能偷了。 猜测农场停机之后,作物和动物的生长计时应该是继续的。。。嘿嘿,所以12点不去偷菜,更待何时。

        可惜我对自己农场的收割过程,是伴随着不断提示超时提示。通过锲而不舍的刷新-重试总算完成了收割,随后点击好友列表,抛异常!

        

        同一时刻微博上已经有人喊“收菜收到手抽筋”,于是乎对这个故障做了以下假象判断:

        1.在线用户突破2000w,肯定是要将用户垂直分区的。分区带来的优点是快速扩容、在故障时后只有部分用户的有损,因此在恢复的时候,有先有后也不足为奇。

        2.分区带来的最大问题就是“聚合”,两个不同区的用户互为好友,拉好友菜园信息需要跨区。 这里就有比较多的技巧了。 目前互联网兴起的All cache,内存bigMap之类,正适合用于处理sns链。

        3.内存db和全量cache带来的问题是可靠性,可以说是葵花宝典!用好无敌,用错很伤。 其一,对数据的持久化问题决定了应用场景只可以是农场,sns聊天,绝对不会是拍拍网的订单或者cft的支付流程。 其二,大量cache虽然能持久支撑并发,可是服务重启之后, 重新初始化cache的策略,以及无cache的瞬间访问压力,都可能导致后台直接down。

机。 拉不到好友列表,应该属于cache重建期间的问题。

        4.由此引申出一个问题。。4.21号农场停机应该也是个不小的挑战,如何确保数据的一致性?或者是金币补偿方式?

         大并发带来的不止是正常服务情况下的优化,对整个系统的“可用性”是赤裸裸的掠夺。构建高性能站点,需要更综合、全面的视角和扎实的基础。

~~~后续体验的一些补记:

1.为啥牧场、农场在操作后,再刷新自己的园地,90%都会长草、出现苍蝇呢:)

    个人理解为触发式任务,总比定时扫描所有用户数据要明智很多:) 广义上用户的操作习惯和登录间隔是符合随机分布的。 在互联网中,“最终一致性”的概念应该一直牢记,并不断衍生

猜你喜欢

转载自sw1982.iteye.com/blog/649982
今日推荐