• Feeds

  • Archive for November, 2010


    多IDC数据时序问题及方法论

    上一周在微博架构与平台安全演讲中提到多IDC及架构设计的方法,由于最近工作中经常碰到这种情况,再举一个小案例补充一下。

    Web数据访问比较好的设计模式是使用cursor方式(参考前文用Twitter的cursor方式进行Web数据分页),原理上相当于增量方式访问数据,可以极大提高访问性能。

    在单IDC场景中,如图1,系统的id是递增,假设用户上一次访问最新一条记录是1002,则本次访问最佳的方式是 get?cursor=1002,可以高效取到后面3条新记录。

    多IDC场景,看图2,假设白色背景属于Region 1,灰色背景属于Region 2, 由于两地同步有延迟,这样在Region 1中1001和1003来到时间较晚,排在本地数据1002和1004后面。假设用户上一次也是取到最新一条是1002(注意此时1001没取到,因为从外地未同步过来)。在Region 1调用 get?cursor=1002返回结果会得到什么?从数据库角度来看,访问cursor=1002 只会取到id>1002的记录,而上次未取到的1001即使已经同步过来是永远不会返回了。这样就产生了数据一致性问题,1001丢了。另外一个机房Region 2调用也产生类似问题。不同的cursor产生不同的丢失问题。

    提出这个问题后身边很多技术人员非常感兴趣,经常走在路上被拦住介绍他们突然想到的一种更巧妙的解决方法。部分思路如下
    (这里先不考虑ID递增算法如何实现,多IDC使用K-SORT方式递增也是比较容易的)

    • 例外的方式,把迟到的id都存下来
    • 补方式,把cursor往前多取一点,宁滥毋缺
    • 快照方式,最近取的记录都存下来,这样服务器内部知道这个cursor上次哪些id取了哪些没取

    大部分方法貌似都能工作,但都有问题或不完美,更重要的一点,也就是上周演讲中提到的,架构要把复杂的问题抽象简单,很多技术人员面对这个问题,并没有深层次思考这个场景的问题本质是什么,因此虽然匆匆考虑了很多复杂的解决方案,但是没有完美解决问题。

    有兴趣的朋友可以继续思考,看能否将复杂的问题抽象简单并解决?

    微博架构与平台安全演讲稿

    本文是在2010中国首届微博开发者大会演讲稿(PPT),由于网上已经有演讲视频及全程文字记录,这里就不做补充,演讲稿如下。

    需要下载请点击 view on Slideshare,在 Slideshare 打开后 Download