缓存模式
基于内存buffer的发号器架构如图，这也是目前我在维护的发号器之一
优点：
1.水平扩展方便
2.对高并发支持良好
3.数据库依赖较低，只在buffer耗尽时需请求数据库，连接失败情况下仍可实现较长时间发号
4.该服务目前支持step发号返回的id格式符合 id=startID+idStep*n
5.该服务支持一次获取多号，性能与单个发号相近
缺点：
1.集群情况下，发号为趋势递增而非严格递增（趋势递增指ID整体上是增加且唯一的，但不是严格两次发号都差1，比如两台服务器A持有1001-2000 B持有2001-3000 两次发号请求分别到了AB两个机器，得到1001 和2001）
2.重启服务后未用完的号段作废
实现：
服务以worker方式工作，一个serviceID对应一个worker，以服务A为例
服务A初始化，创建worker ，访问数据库根据max_id获取2个号段填入内存buffer
获取的号段segment驻留内存，号段数据结构【startID，currentID，MAXID】，之后每次取号只访存修改currentID，有锁机制保证线程安全
一个号段用完后利用go信道获取buffer中的新号段，同时服务会生成并填充新号段入buffer保证buffer中一直保有2个号段（可配置），服务期间除初次启动，请求发号不依赖数据库，数据库连接失败后仍可持续发号较长时间（取决于号段长度step_size及服务请求量）
服务周期内，所有请求只经历访存延迟，buffer抹除了数据库延迟
有疑问加站长微信联系（非本文作者）
