星河之洲

我开发的第一套缓存中间件是cachex。cachex支持自定义存储后端，实现了哨兵机制，自带lru存储，支持系统故障时使用过期缓存数据。

cachex的主要问题是不支持批量处理。这也导致在上家公司，cachex未能上阵。我在上家三年时间一直不能开发出支持批量处理的缓存中间件，我也写了三年业务耦合的缓存处理代码。

这次的restcache是fastrest组件库的一个组件。在写restcache之前，我创建了gox项目，实现了优化版的lru，和一套完整的支持批量处理的哨兵机制，然后再实现restcache就简单多了。解决一个复杂问题的一个有效方法，就是模块拆分。

一套完整的缓存，应该包括三个模块：存储、查询、中间件。三个名字是我取的，不准确。

• 存储是存储缓存数据的部分，也可以称为后端，一般是redis客户端，或者进程LRU存储。存储逻辑都是透明处理业务数据，也就是存储逻辑是通用的，不用对每个业务逻辑写一套存储代码。
• 查询是存储查不到目标数据时，提供新缓存数据的部分，一般是从MySQL等持久化数据库或者服务接口查询。很遗憾，查询逻辑是耦合业务数据的，需要对每个缓存业务写一套定制的查询代码。
• 中间件是响应用户查询，调用存储和查询的胶水逻辑，也就是实现了典型的缓存流程。这个也是通用的。

cachex和restcache实现的就是缓存的中间件，并定义了存储和查询的接口。restcache的用户需要自己实现存储和查询。restcache已经附带了一套lrucache存储，可以直接用。但因为用户的redis库版本会不同，restcache没有实现redis存储。

典型的缓存流程如下：

• 先查存储。如果找到，返回结果，结束；如果没找到，可能是因为没存或者已经过期，继续下一步。
• 调用查询，查到新缓存数据，保存到存储，返回结果，结束；如果没查到，返回notfound，结束。
• 下次查存储，查到上一步保存的新缓存数据。糟糕的情况是notfound，会重复第一、二步。

应该绝大多数缓存都是这个流程。这个流程的主要麻烦有两个：

• 缓存失效风暴，即大面积缓存失效。缓存本意是避免执行大量重复的低效的查询，但大面积缓存实效会降低缓存的意义，严重的会导致后面的服务失去服务能力。
• 批量查询。实际场景中，很多列表的查询。批量处理，会让流程中的每个环节变复杂。

解决方案为：

• 对于缓存实效风暴，cachex和restcache都用上了哨兵机制。我实现的叫SentinelGroup，Go团队实现了一套singleflight。SentinelGroup不见得写得比singleflight好，但强在支持批量处理。两者核心逻辑都是一致，多个过程需要同时取得相同的结果，只放行一个去做生产者，其它作为消费者等待生产者分享结果。
• 对于批量查询，这是cachex无法实现，但restcache实现了的特性。重复下：解决一个复杂问题的一个有效方法，就是模块拆分。一个复杂模块，由几个小模块简单地构成，每个小模块都封装了一部分复杂逻辑。然后小模块又可以继续拆分为几个更小的模块。cachex的失败，在于没划分清楚缓存和哨兵机制的边界，没能定义出清晰简单的批量存储接口，导致单个模块过于复杂。解决了实现的复杂性，简单来说，缓存的批量处理，就是要从不同的来源查询数据，再把不同来源的数据组装起来。第一步需要从存储和查询中拿到数据，第二步需要从哨兵机制的生产者和消费者拿到数据。因为这两步的边界足够清楚，也就降低了整体的复杂度。

restcache刚刚开发出来，虽然我写了很多单元测试，但经过项目的考验才能成为一个成熟稳定的组件。

以前我在公司写过一个简单的Go热升级支持程序。但是工作时间写的，领导不准开源。后我想另写一个开源版本，但一直没想到解决多端口的问题。后来就慢慢忘却了。

直到最近一次偶然的机会，这个程序被人重新提起。又遇上待业期，正需要写点东西打发时间。突然灵感来了，想到了多端口的解决方案。

于是有了reloader。

思路基本是之前版本的扩展版。一个master进程，多个worker进程，一个worker进程处理一个侦听器。这样可以实现多端口的动态侦听和关闭。我又做了些进程管理的优化，推送到github。

无法否认，我的解决方案存在很多问题，因为偷偷起了多进程。比如程序在所有侦听器和连接都关闭后需要上层逻辑结束，这对于单进程无碍，对于reloader却是可能多了N个垃圾worker进程。这些问题，得等待找到更好的解决方案。