上一周在微博架构与平台安全演讲中提到多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取了哪些没取大部分方法貌似都能工作，但都有问题或不完美，更重要的一点，也就是上周演讲中提到的，架构要把复杂的问题抽象简单，很多技术人员面对这个问题，并没有深层次思考这个场景的问题本质是什么，因此虽然匆匆考虑了很多复杂的解决方案，但是没有完美解决问题。
有兴趣的朋友可以继续思考，看能否将复杂的问题抽象简单并解决？