[构建高性能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%都会长草、出现苍蝇呢：）

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