High Performance Weibo QCon Beijing 2011
View more presentations from Tim Y.
提示：
- QCon网站提供此演讲下载的PDF是老版，大约有30%的内容改变，已经通知Update
- Slideshare文档在对方网站可浏览及下载，但是下载只提供Mac OS Keynote格式，PDF格式太大未提供(上传转换1小时未完成)，有需要可以到QCon Beijing官网下载
构建高性能的微博系统(QCon Beijing 2011演讲)
如想及时阅读Tim Yang的文章，可通过页面右上方扫码订阅最新更新。
« 一次内部Scala编程竞赛 | 《Erlang编程指南》读后感 »
不知道weibo的cache具体怎么设计的，好感兴趣
几个小问题，劳烦 Tim 指教：
1. 相对于硬盘，内存的存储速度的确有很大的优势。但是内存数据并非可持久保存。若遇到当机等情况，数据就会丢失。因此，若是将所有数据放入内存，如何实现数据的持久性（Durability）——是否是replicate到多台机器的内存上。
2. Slide 41 提出了“第五步破坏了实时性和一致性”，但是提出的解决方案似乎并没有解决“一致性”的问题。
期待视频发布
为啥不用pdf格式呢？离线没法看，S！
pdf看了也看看视频
一直好奇微博这样高负载的系统，如何利用缓存
在分布式系统的设计上，我觉得有三点。
1.对于多链路进入不同IDC间的流量分布支持。在中国有时候是没办法的事情，各个IDC之间的网速有时候是不能保证的（自己有光纤的除外），在不同地方登陆到分布式数据中心进行运算处理的最优链路选择，是一个难点。
2.对于分布式运算的计算和存储一般是分开的，存储可以使用key-value结构进行构造，运算单元作为脚本可以分布在不同的服务器上，同时key-value尽量减少单点故障，也要有集群和冗余的概念。在这方面开源的选择上，成熟的方案一般是需要大量时间和技术成本验证的。
3.感觉数据库这种东西，越来越作为后端关系型存储而存在，便于后端维护系统的开发，而在实际内核应用中，cache和网格计算是主流，甚至可以完全不用知道DB的存在。另外，对于灾难恢复，如何做到恢复到上一时刻的内存镜像，一直是一个难点，对然可以通过共享内存以及一些cache工具，但是做到完全实时几乎是不可能的。
我最近在做一个游戏”大世界”的概念，和你的思想很类似，计算资源完全可以分布在各个服务器上去做，如果需要只需要横向展开，不过，对于cache的管理和维护，我有一些想法还未经过大量的实际检验，很希望和你能有交流。我的QQ是 41198969，希望能和您成为朋友。一起探讨高并发可用性的分布式网络服务。