正文
}
});
});
timer.run();
关于第二点，要稍微复杂点了，怎么搞呢？
来这么分析：
-
数据 messages.
-
操作 op-log.
-
偏移 position/offset.
// 1. 先考虑messages
// 2. 再考虑log的postion或者offset
// 3. 考虑msg和off都记录在同源数据库或者存储设备上.(database or storage-device.)
var timer =
new timer()
.setInterval(10sec)
.onTime(slave-nodes,function(nodes){
var core-of-cpu = 8;
//嫌慢就并发呗 mod hash go!
nodes.groupParallel(core-of-cpu)
.forEach(node -> {
boolean nodeSucked = false;
if(node.ackTimeDiff > 30sec) {
//30秒内没有回复，node卡住了
nodeSucked = true;
}
if(node.logOffsetDiff > 100) {
//node复制跟不上了，差距超过100条数据
nodeSucked = true;
}
if(nodeSucked) {
//总之node“死”掉了，其实到底死没死，谁知道呢？network-error在分布式系统中或者节点失败这个事情是正常现象.
node.declareDeadOrFailed();
//不和你玩啦，集群不要你了
nodes.remove(node);
//该怎么处理呢，抛个事件吧.
fire-event-NodeDeadOrFailed(node);
}
});
});
timer.run();
上面的节点的状态管理一般由zookeeper来做，leader或者master节点也会维护那么点状态。
那么应用中的leader或者master节点，只需要从zookeeper拉状态就可以，同时，上面的实现是不是一定最佳呢？不是的，而且多数操作可以合起来，但为了描述节点是否存活这个事儿，咱们这么写没啥问题。
节点死掉、失败、不同步了，咋处理呢？
好嘛，终于说到failover和recover了，那failover比较简单，因为还有其它的slave节点在，不影响数据读取。
-
同时多个slave节点失败了？
没有100%的可用性.数据中心和机房瘫痪、网络电缆切断、hacker入侵删了你的根，总之你rp爆表了.
-
如果主节点失败了，那master-master不行嘛？
keep-alived或者LVS或者你自己写failover吧.
高可用架构（HA）又是个大件儿了，此文不展开了。
我们来关注下recover方面的东西，这里把视野打开点，不仅关注slave节点重启后追log来同步数据，我们看下在实际应用中，数据请求（包括读、写、更新）失败怎么办？
大家可能都会说，重试（retry）呗、重放（replay）呗或者干脆不管了呗！
行，都行，这些都是策略，但具体怎么个搞法，你真的清楚了？
一个bigdata问题
我们先摆个探讨的背景：
问题：消息流，比如微博的微博（真绕），源源不断地流进我们的应用中，要处理这些消息，有个需求是这样的：
Reach is the number of unique people exposed to a URL on Twitter.
那么，统计一下3小时内的本条微博（url）的reach总数。
怎么解决呢？
把某时间段内转发过某条微博（url）的人拉出来，把这些人的粉丝拉出来，去掉重复的人，然后求总数，就是要求的reach.
为了简单，我们忽略掉日期，先看看这个方法行不行：
/** ---------------------------------
* 1. 求出转发微博(url)的大V.
* __________________________________*/
方法 ：getUrlToTweetersMap(String url_id)
SQL ： /* 数据库A，表url_user存储了转发某url的user */
SELECT url_user.user_id as tweeter_id
FROM url_user
WHERE url_user.url_id = ${url_id}
返回 ：[user_1,...,user_m]
