写在最前面
今天下定决心说不写其他的文章了，但是还是没忍住，想把现在接触到的东西都赶快的记录下来，防止以后忘记。还有可能就是越得不到的东西越珍惜吧，所以想赶快把他记下来，把想法记下来。以后可能有一天我有能力或者有决定权的时候或许可以用上~
计数服务
计数服务，简单来说就是一个打点服务，看似很简单，不就是进行一个数据的累加吗，有什么的？但是可真的不是这样的。计数可以帮助我们干很多很多事情。例如服务的异常数，服务的调用次数，哪些接口的调用次数，等等等。
计数服务可以做什么
我们都知道时间序列这个词，这个词代表每个时间点上的数据数量的集合。我们有了计数服务其实我们就得到了某个指标的对应时间序列。有了时间序列以后我们就可以知道很多信息，例如系统是否有高峰点，例如系统哪些时间发生的异常比较多。例如哪些业务逻辑走的比较多等等。
最终要的，有了时间序列我们甚至可以对数据进行预测，对数据进行异常检测。
这么一说，是不是觉得计数服务就是很有必要的了呢？
现有的计数服务
目前其实也有计数服务，例如美团点评的CAT，这里给CAT打个小广告吧，真心觉得这个产品做得非常棒！
但是CAT也会有一定的瓶颈，例如CAT的数据延迟比较高，我们上报一个数据以后可能很长时间才能看到真正的数据。还有就是CAT的数据存储方面了，不支持太多的持久化数据存储。
所以基于以上几点，自己做一个计数服务势在必行了。
计数服务的架构图
关于计数服务，主要是依赖于客户端的汇聚操作和远程的通讯操作，数据存储在远程，远程的Redis或者其他的计数器作为全局计数器，这个全局计数器的集群需要高可用，可以用集群自带的高可用操作。
主要有以下几个核心点组成：
- 负责客户端逻辑，也就是本地进程内进行数据汇总的client客户端。客户端内要有几个关键点，一个是
countBuffer负责汇总一段时间内的请求数量，与远程交互的RedisClient，异步进行上报的ReportThread。还有就是负责异常处理的ErrorHandleThread。当然如果是同步累加的话每次与Redis进行交互就可以了。 - Redis集群，负责核心的全局计数器操作，这个全局计数器主要灵感来源于限流算法，限流算法有几种
令牌桶，漏桶，全局计数器，这个地方就利用了全局计数器的这个概念。值得注意的是key的设计，每分钟或者每秒设置对应的key，从而区分每个计数的粒度。这个地方需要注意热点key的出现（不过因为是间隔时间还可以所以基本上不会太出现） - Shower这个名字真心是拍脑袋想出来的，其实就是一个数据展示，建议数据展示还是直接操作从的Redis把，定时同步出来一个，防止读写同时发生时候性能降低，也防止把主的查挂了。主要提供一个数据展示的视图，或者提供一个数据查询的API.
多说一点
这个其实是依赖于远程的Redis做的计数，其实如果是实时性比较强的，感觉可以参考Hystrix的dashboard的做法，把数据直接存储在客户端里面，每次查询的时候访问每个客户端，实时汇总数据。这样的到的数据更加实时，而且可以区分上报的机器信息。
感觉自己真的是很奇怪，可能因为是天秤座，天生不是很喜欢被束缚
