Cache策略

  • 定时过期策略
    1. 定时过期的好处是Cache节点的个数符合实际需求，不会造成资源滥用和服务器压力
    2. 定时过期适合访问量较大，实时性要求不高的情况
    3. 如果访问量小，定时过期会造成Cache命中率低，如果实时性要求高，过期间隔太小，Cache的意义就不大
    4. 适用情况 : 实时性低
  • 全量刷新策略
    1. 全量刷新的好处是Cache命中率高，Cache实时性高
    2. 全量数据相比那些Cache key值设置不好的非全量Cache,可能反而更小
    3. 全量刷新的弊端是有可能造成服务器的压力，如果数据使用率低，就是对资源的滥用
    4. 全量刷新适合数据量小或者数据使用率高的应用
    5. 适用情况 : 数据量小
  • 定时刷新策略
    1. 定时刷新的Cache节点个数和Cache大小成正比，需要综合考虑Cache命中率和数据量设定节点个数
    2. 节点数过大会造成Cache庞大，过小会造成命中率低
    3. 定时刷新的频率和实时性成正比
    4. 定时刷新对服务器资源有一定的滥用
    5. 需要开发人员了解具体服务的访问量数据量，制定合适的节点个数与刷新频率
    6. 使用情况 : 其他策略无法满足
  • 定时过期+磁盘持久化策略
    1. 过期Cache存磁盘文件，系统下线所有cache持久化
    2. 分布式Cache机制，互相备份，错开重启
    3. 可以在一定条件下舍弃数据库
  • Cache与访问量，数据量，定时性的关系
    1. 访问量大，数据量大，实时性高，可以使用复杂的定时刷新，还需要根据实际情况做优化
    2. 访问量小，数据量大，实时性高，可以使用定时刷新或不用Cache
    3. 数据量小，实时性高，可以使用全量刷新
    4. 访问量大，数据量大，实时性低，可以使用定时过期
    5. 访问量小，数据量大，实时性低，可以使用定时过期或者定时刷新

智能Cache策略

  • UserPreference cache
  • Subscription cache
  • 分时间段的Cache,某些时间段的某些cache不过期，需要通过分析流量制定时间段

穿透优化

  • 缓存穿透
    1. 发生大量不存在的key的访问，会加重对数据库层的压力
  • 优化方法
    1. 缓存空对象key:null
      1. 空对象使用一个比较短的过期时间
      2. 用主动刷新策略应对key又被存入数据库的情况
      3. 实现成本低，占用内存不可控（由非法key和合法key的比例决定）
    2. 布隆过滤器拦截
      1. BloomFilter缓存所有存在的key，进行第一层过滤
      2. 会降低缓存的性能，实现成本高，占用内存可控
    3. 不使用传统的低性能的数据库

无底洞优化

  • 无底洞现象
    1. 分布式存储随着节点数的增加以及key的随机分布，批量操作的网络传输次数怎加造成性能不增反减
  • 优化方法
    1. 串行IO
      1. 先将批量查询的key所在的节点做mapping
      2. 属于相同节点的key合并一组，循环的所有组进行查询
    2. 并行IO
      1. 对串行IO作多线程处理
    3. hash tag
      1. 将相同hash tag的数据存储在同一个节点
      2. 一次批量查询只操作相同hash tag的key
      3. 容易产生数据分布不均衡

缓存重建优化

  • 问题
    1. 高并发的热点key+数据对象大重建缓慢
    2. 数据过期等情况造成大量线程来重建缓存，使得服务崩溃
  • 优化方法
    1. 永不过期或者timeToIdle+主动更新
    2. 互斥锁：Redis可以用setnx实现
    3. 用户请求不重建缓存，用单独线程合并用户请求重建缓存

热点key集中化优化

其他等待解决疑问

  • Server resource的个数大小如何定
  • resourcePool的个数与大小
  • Manage the CacheManager/Cahce/Entity
  • load balance
  • Thread Pools线程池
  • key生成策略

CacheManager/Cache等实例数量与大小的考虑

  • server resource & resource pool
    1. server resource可以多设置几个，比如每个1-5G这样，设置5个备用，每个可以给一个CacheManager使用
    2. 一个server resource里可以设置一个或多个resourcePool用于clusteredShared，一个或多个resourcePool用于clusteredDedicated，这个要根据实际需求
    3. 一旦clusted端建立了CacheManager，此CacheManager所占用的resourcePool就会被分配给这个CacheManager，所以resourcePool的大小应该更具项目实际情况设置，以免造成资源浪费
    4. 一个pool满了，就使用下一个，而不是增加它的大小，不然会影响所有使用者
    5. 也可以使得pool的大小动态获取，而不是hard code
  • CacheManager
    1. 不同的业务模块创建不同的CacheManager实例，可以保持业务模块独立性
      1. 比如说可以单独清除一个CacheManager的所有Cache
    2. 多个CacheManager,配置代码在不同项目的复用会出现问题，如何解决？
      1. 用一个项目创建CacheManager,其他项目用缺省的方式连接CacheManager
    3. 单个CacheManager和多个CacheManager的性能问题？多个CacheManager真的必要么？
  • Cache
    1. 不同的业务模块创建不同的Cache实例，可以保持业务模块独立性
      1. 不同的业务模块可以使用不同的key规则
      2. 可以独立的管理cache，比如删除等操作
      3. 可以更合理的定制Cache大小，提高cache命中率
      4. 可以更合理的定制Expiry
    2. 通过不同的Expiry策略创建不同的Cache实例
      1. 方便开发，无须每次都创建新的cache
    3. clusteredDedicated
      1. 必须指定cache的大小，不适合producer/consumer的方式，因为consumer必须知道producer设置的大小
      2. 能够更好的更具实际需要利用内存资源
    4. clusteredShared
      1. 不需要指定每个cache大小，方便producer/consumer主从互换
      2. Shared pool的大小必须足够大，而且基本不变，才能方便使用，这样便会造成内存的浪费
      3. Shared pool的变化会造成所有producer/consumer的配置要变
    5. clustered继承
      1. 解决了clusteredDedicated的问题
      2. 但是如果有两个以上的producer或者spring cache那样自己也是producer，还是必须统一配置
  • 不方便的地方
    1. spring cache无须手动create cache，但是ehcache clustered必须手动，因为每个cache的配置更灵活
    2. withCache/createCache创建新cache，必须用autoCreate,在原来的CacheManager实例里创建新的cache并且连接
  • 动态cache配置机制
  • 多个Cache不同项目的配置
    1. 配置服务化[不推荐]
      1. 将配置信息封装成配置对象
      2. service提供获取配置对象服务
      3. 造成client项目依赖service或者cache项目
    2. 主从互换
      1. service与client都去判断cluster端是否存在cache，如果不存在，那么创建，否则继承
      2. 造成cache manage也无法继承
      3. 无法保证service与client创建cache时使用相同配置
      4. 适合clusteredShared
      5. 不适合clusteredDedicated的原因是client必须知道service端设置的大小
      6. 如果有两个以上的producer，也不适合clustered继承
    3. 完美主从互换[跨项目组的情况下建议使用]
      1. 方法1: service提供Cache配置服务，client获取配置创建cache，配置服务使得service必须有服务提供
      2. 方法2: common jar的形式保证创建cache时使用相同配置
      3. 方法3: service方提供client代码,client利用client代码创建cache
      4. 保证service与client创建cache时使用相同配置
      5. service必须知道自己的cache的配置，无法使用动态cache配置机制
      6. 需要动态cache配置的时候只适合clusteredShared，否则可以使用clusteredDedicated
      7. 这个工作需要额外开发，很麻烦啊，两害取其轻，还是使用clusteredShared+动态pool size吧，一点点浪费总比不可控也增加开发/维护难度好
    4. service主导[不推荐]
      1. client判断cluster端是否存在cache，如果不存在，那么创建，否则继承
      2. service判断cluster端配置是否符合自己要求，如何不符合，删除cache重新创建,否则直接创建
      3. 但是必须所有cache manager close()
      4. 适合clusteredDedicated