善用本地缓存
7年前见过一个别人做的项目：因为公司的视频和专辑这些媒体资讯信息属于基础数据，非常重要。有个基础服务专门将这些基础数据提供给全公司使用。这些数据都是从后台信息中录入的，全量数据数据库中有存储，并全量存到了集中式缓存中。
全量数据大概不到500M。但是存在一些大专辑，就是说有的数据一条就占几M。所以在查询时，特别是请求多的时候遇到很多超时现象。毕竟像redis等集中式缓存都不建议缓存大数据。
但是我们这个服务特别重要，请求量大，SLA要求高，得缓存啊。这时我建议直接使用本地缓存。很多人在设计的时候有个误区：有了集中式缓存再用本地缓存好像不够高级。最高级的用法是采用合适的技术。
咱们以终为始的来考虑问题：集中式缓存的好处是数据一致性高，一旦数据更新了。从哪台应用服务器取的数据都是一样的。但是咱们目前的情况是数据是后台录入的，本身就有人工时间误差。所以定时1分钟、2分钟从数据库刷新一次检查数据有没有变化也是可以的。每个服务有一定时间差也是可以容忍的。所以集中式缓存的必要性并不高。
有人说本地内存很珍贵呀。咱们来算一算哈。一般这种核心的系统，随着请求量的增加，IO会增加、CPU会增加，基本与请求量成线性关系。当然每个请求都要占用一定内存，拿Java语言来说。主要是年轻代的占用。像这种大数据一直在内存中的就直接进入老年代了，当然也可以直接使用堆外内存。因为JVM等存储各个内存区大小固定，请求增多会导致年轻代的young gc频率升高，其实对老年代影响并不明显。
其实可以验证一下，请求量升高时，内存的使用量变化很少。所以内存影响是可以计算的。比如咱们4C8G的虚机，内存多使用500M，只要JVM参数设置合理，对一般程序来说都是可以接受的。
使用这种方案，避免了集中式缓存大value引起的各种超时等问题，很多请求下反而更优。
不兼容版本设计
当开发了一个接口2.0，产品设计人员的设计与原来1.0完全不兼容。1.0已经有用户在使用了。怎么办呢？
当遇到一个问题，不知道怎么做更合适的时候首先要做业界调研。
微信开放平台的做法：
在url中标明版本号，按照版本号进行路由。不同版本对应不同的实现，并且将不同版本的请求不同点都体现在文档中。接入方就不会质疑版本不兼容问题了。
编程一生
因为公众号平台更改了推送规则，如果不想错过内容，这样每次新文章推送才会第一时间出现在你的订阅列表里。
想知道自己错过了哪些更新，可参考我不定期更新的《系列文章分类汇总》。
