架构之缓存设计

缓存能够是本地缓存，也能够是分布式缓存；能够本身写个简单的程序，也能够搞个复杂的独立系统做为缓存；可使用各类复杂的算法，也能够只使用简单的全量缓存；可使用各类失效机制，也能够只支持人工刷新。缓存重点在于技术，但缓存的难点在于分析哪些数据能够缓存，以什么样的策略缓存。有些数据一看就是能够缓存的，好比参数数据；但若是给参数加个限制条件，好比虽然参数修改不多，但一旦修改就须要在系统调用时实时生效，那这种状况下是否还能够缓存？下面试着选择一些经常使用的场景来分析是否可使用缓存。

一、系统参数数据，修改频率很是低，通常由开发人员修改

系统参数是由开发人员修改的参数，开发人员每次修改后，可经过人工刷新缓存参数便可，只须要提供一个手工刷新的页面，让开发人员在更改了系统参数后手工刷新便可。

二、业务参数数据，不多修改，修改后必定时限内生效（好比一小时后生效，或隔日生效等）

这种场景下，除非系统无性能要求，通常都会对参数数据进行缓存。参数数据由于有个特色就是数据量较小，故通常就是全量缓存，一次刷新，无需设置失效时间。缓存的刷新机制也相对比较简单，通常能够经过写一个定时刷新程序每一小时或天天全量刷新一次缓存。或者也能够经过设置失效时间，直接在刷新缓存数据时设置缓存数据的失效时间是一个小时之后或当天23点59分59秒，这样当一小时后或次日查询参数时发现已经失效就自动刷新一次。

三、业务参数数据，不多修改，修改后必须当即生效

这种场景下，若是没有性能瓶颈，那就不作缓存了，系统设计越简单越好。但若是确实存在性能瓶颈，那就必须作缓存了。这种状况乍一看无法缓存，但咱们分析一下，业务参数是会修改且当即生效，但修改的是不多的参数，绝大部分参数仍是不会被修改的，在很长时间内是不变的，是能够缓存的。在这种状况下，失效时间和定时刷新机制已经不适合了，须要引入新的实时刷新机制，能够考虑消息机制来通知缓存的刷新。当业务参数改变后，发送消息通知缓存系统或缓存功能当即刷新缓存，这样作固然是侵入了业务代码，但为了提高性能也只能这样了。

四、多个传入参数计算后的结果数据

这些数据通常由多个传入参数通过较为复杂的业务逻辑计算后获得结果，这些结果数据是后续业务的传入参数，好比策略计算结果。这种情景中，若是存在性能问题，则须要对计算结果进行缓存，能够将传入参数组合的hash值或MD5值做为key缓存计算结果，这样当下次一样的传入参数组合就只须要从缓存中获取计算结果便可，这样的缓存通常状况下量会比较大，能够考虑使用分布式缓存系统或者使用在本地使用替换算法来控制缓存的数量。这种缓存数据在计算逻辑不变动的状况下是不须要更新的，只有当计算逻辑变动的状况下，须要刷新缓存，若是全量比较大，能够考虑给这类数据按照计算逻辑编制成组，在计算逻辑变动后刷新此计算逻辑影响到的组的缓存数据便可。还有一种办法就是预热，通常业务计算逻辑变动就须要上线，会有足够的时间预热缓存。

五、部分业务数据的缓存

业务数据要缓存，这个看起来是不可能的。但有时候系统性能硬逼着必须使用缓存，好比并发性很是的高，数据库访问性能已经没法跟上，不然会致使数据库的崩溃。这种状况下，必须对业务数据进行分析，可能对全部的业务数据缓存不太可能，可是否能够缓存部分，这须要细致的分析。好比业务进度查询这个功能，咱们来分析一下，进度查询功能对客户来说，通常是查询最近一段时间内的进件的进度，这种查询量可能占到了查询量的绝大部分，那么咱们能够将最近这段时间的进度信息缓存起来，以提高查询的性能。但最近时间的进件，其进度信息也是修改频率最高的，那么如何在这种矛盾下提高这些数据的查询性能？这就是难点所在。业务和数据分析以及对数据分类处理是解决这种矛盾的一个有用手段，经过业务和数据的分析，确定能找到这个平衡点。

 

点击连接加入群【.NET大型网站架构】433685124QQ群