首页 > 代码库 > 妹纸小A的计数工作
妹纸小A的计数工作
文中所述事情均是YY。
小A是一个呆萌的妹纸,最近刚刚加入小B的团队,这几天小B交给她一个任务,让她每天统计一下团队里九点半之前到公司的人数。
九点半之前到公司人数
于是,每天早上小A都早早来到公司,然后拿一个本子来记,来一个人就记一下。 [1]
这里,其实小A的做法和下面的代码一样:
public class SimpleCounter1 {
List<CheckRecordDO> counter = new LinkedList<CheckRecordDO>();
public void check(long id) {
CheckRecordDO checkRecordDO = new CheckRecordDO();
checkRecordDO.setId(id);
counter.add(checkRecordDO);
}
public int count() {
return counter.size();
}
}
每当小B问有多少人已经来了的时候,小A只要瞅一眼本子上记录的人数就能立马回答了。
过了几天,小A发现,同学们上班的时候不是都一个一个来的,有的时候一下子同时来了好几个人,就会有漏记下的,该怎么解决这个问题呢?
小A想了一个办法,她让来的同学们一个一个等她记下来了,再到自己的位子上去。这么做以后再也没有出现过漏记的情况了。[2]
小A的这个办法就是加了一个锁,只能一个个串行的来:
public class SimpleCounter2 {
final List<CheckRecordDO> counter = new LinkedList<CheckRecordDO>();
public void check(long id) {
synchronized (counter) {
CheckRecordDO checkRecordDO = new CheckRecordDO();
checkRecordDO.setId(id);
counter.add(checkRecordDO);
}
}
public int count() {
return counter.size();
}
}
可是好景不长,开始几天同学们还能接受小A的做法,时间长了,很多同学就有意见,同学们都不想花时间在等记名字上面。
小A只得改变一下方法,她在每个入口处都放置了一个盒子,让同学来了后自己把名字写在小纸片上,然后放到盒子里,小A数一下盒子里的小纸片数量就能知道来了多少人。[3]
这种做法类似于在数据库里插入几条记录,统计的时候count一下:
public class SimpleCounter3 {
private CheckRecordDAO checkRecordDAO;
public void check(long id) {
CheckRecordDO checkRecordDO = new CheckRecordDO();
checkRecordDO.setId(id);
do {
if (checkRecordDAO.insert(checkRecordDO)) {
break;
}
} while(true);
}
public int count() {
return checkRecordDAO.count();
}
}
虽然有时候一起来的时候人很多,但只需要增加一下盒子的数量,也不会产生拥堵的情况了,小B对小A的方案很满意。
小A使用盒子的思路,就相当于建立分库分表机制,增大并行数量,解决拥堵。
由于小A的计数工作完成的非常出色,于是,其他团队的计数工作也都移交到小A这边了。呆萌的小A原本只需要统计二十几号人,现在一下子增加到了几百号人。小A每次数盒子里的小纸片数量都需要花费比较长的时间,顿时,呆萌的妹纸又陷入了淡淡的忧伤当中。
这时候旁边的小C站了出来,对小A说,其实小B并不关心到底来了哪些人,只需要知道来了多少人就可以了。
小A一下子明白过来,立马改进了方法,在每个入口设置了一个号码本,每一个同学来的时候撕下一个号码,小A只需要把几个入口的号码本上待撕的数字加一下就能得到总数了。[4]
public class ParallelCounter1 {
final int ENTRY_COUNT = 5;
Counter[] counter;
{
counter = new Counter[ENTRY_COUNT];
for (int i = 0; i < ENTRY_COUNT; i++) {
Counter c = new Counter();
c.value = http://www.mamicode.com/0;>
不幸的是,问题还是来了,由于每个入口进来的人数不一致,有些入口的号码本很容易早早用完,另外一些入口却还剩下不少。
小C是一个热心的man,这时候又站出来了,他说,既然各个入口的人数不一样,那么按照人数比例设置号码本数量不就可以了么。于是小A在各个入口处设置了不同数量的号码本,果然问题解决了。[5]
现在小A的做法和下面的实现一样,每一个entry有不同数量的counter,每个员工check的时候随机选择一个counter:
public class ParallelCounter2 {
final int COUNTS = 16;
final int ENTRY_COUNT = 5;
Counter[] counter;
Integer[][] entryCounter = {
{0,0},
{1,1},
{2,3},
{4,7},
{8,15}
};
{
counter = new Counter[COUNTS];
for (int i = 0; i < COUNTS; i++) {
Counter c = new Counter();
c.value = http://www.mamicode.com/0;>
按代码所示:
总共有5个入口,使用了16个号码本。
经过这样调整之后,即使有时候有入口因为施工或其他原因临时关闭,也只需要调整一下每个入口的号码本数量就可以了。
前20人送咖啡券
经过一段时间的统计,小B发现,大多数时候九点半前到公司的人数都不超过20个人。怎么才能让大家早点来公司呢?小B想了一个办法,每天前20个来公司的人送咖啡券。
小A想,要给前20个人发咖啡券,那只要记下每个人来的时间,给最早的前20个人发就可以了。可以用之前放置盒子的方法,让每个来的人写下自己的名字和来的时间(价值观保证写的时间是真实的,-_-),最后按时间统计出前20名发咖啡券就可以了。[6]
代码描述相比之前也只是有很小的改动:
public class SimpleCounter4 {
private CheckRecordDAO checkRecordDAO = new CheckRecordDAO();
public void check(long id) {
CheckRecordDO checkRecordDO = new CheckRecordDO();
checkRecordDO.setId(id);
checkRecordDO.setTime(new Date());
do {
if (checkRecordDAO.insert(checkRecordDO)) {
break;
}
} while(true);
}
public int count() {
return checkRecordDAO.count();
}
public void give() {
checkRecordDAO.updateStatusWithLimit(1,20);
}
}
小B觉得,事后发放咖啡券不如即时发放效果好,让小A在同学们来的时候就发。小A一下子又陷入了淡淡忧伤当中。如果只有一个入口的话,可以把咖啡券和号码本放在一起,让同学们来的时候自己拿一张,而现在有好几个入口,每个入口来的人数都不固定,不管怎么分,都可能会造成一个入口已经没得发了,另外的入口还有。
想来想去,小A还是没有想到什么好办法,难道要回到最初,一个一个来登记然后发券?
小A重新梳理了一下发咖啡券的需求,发券的方式要么一个一个发,要么不一个一个发。肯定不要用之前串行的办法,还是得往同时发的方面考虑。按照之前的思路,在几个入口同时都放,将20张咖啡券分配到每个号码本,撕下一个号码的时候拿一张咖啡券。如果一个号码本对应的咖啡券已经被领完了,就从别的地方调咖啡券过来。如果所有的咖啡券已经发完了,那么就设置一个标志,后来的人都没有咖啡券可以领了。[7]
public class ParallelCounterWithCallback3 {
final int TOTAL_COFFEE_COUPON = 20;
final int COUNTS = 16;
final int ENTRY_COUNT = 5;
Counter[] counter;
boolean noMore = false;
final Integer[] coffeeCoupon = new Integer[COUNTS];
final Integer[][] entryCounter = {
{0,2},
{3,8},
{9,10},
{11,12},
{13,15}
};
{
counter = new Counter[COUNTS];
for (int i = 0; i < COUNTS; i++) {
Counter c = new Counter();
c.value = http://www.mamicode.com/0;>
发放咖啡券必须得是先到先得,如果用Pim表示取第i个号码本上号码m的人撕下号码的时间,Cim表示其是否取得咖啡券(1代表获得,0代表未获得),那么先到先得可以这么来表述:
?m > n → Pim > Pin,
? m > n, Cim = 1 → Cin = 1
上面的代码服从这两条约束。
咖啡券发了一段时间后,同学们来公司的时间都比以前早了,各个地方的咖啡券基本上都在同一时间发完,根本就不存在从别的地方调咖啡券的情况。[8]
在各个号码本号码消耗速率保持一致的情况下,小A所需要做的事情也得到了简化,只要平分咖啡券到每个号码本就行了,甚至各个号码本分到的咖啡券数量都不需要预先分配,对应的代码如下:
public class ParallelCounterWithCallback4 {
final int TOTAL_COFFEE_COUPON = 20;
final int COUNTS = 16;
final int ENTRY_COUNT = 5;
Counter[] counter;
final Integer[][] entryCounter = {
{0,2},
{3,8},
{9,10},
{11,12},
{13,15}
};
{
counter = new Counter[COUNTS];
for (int i = 0; i < COUNTS; i++) {
Counter c = new Counter();
c.value = http://www.mamicode.com/0;>
好吧,小A的工作总算告一段落。
小Z
任何事都需要按实际情况来分析处理,不好照搬。小A的最后一种方案是在项目中实际使用的,业务场景是限量开通超级粉丝卡。既然是限量, 便需要计数,便需要检查能不能开卡 。在这个方案里将计数和限量分成了两步来做,计数这一步通过分多个桶来保证并发容量,只要每个桶的请求量差别不大,总的限量就可以直接平分到每一个桶的限量。这里面,最关键的地方在于分桶的均匀。由于是按用户分桶,通用做法便是按id取模分桶,由于用户id是均匀的,分桶也就是均匀的。
妹纸小A的计数工作