memrcache缓存MySQL_multi-layer-cache-example

多级缓存方案

对于性能需求极高、某类对象使用很频繁、对象反序列化和重新装配成本较高的场景,可以通过多级缓存来解决问题。

3bfd430f34a01345631ea010558ac7f6.png

使用很频繁的对象,尤其是读多写很少的情况,适合使用堆内内存来缓存对象。由于堆内内存资源宝贵,缓存一般采用软引用方式,还要限制容量、设定过期时间。

快速变更的简单值,锁,读多写少的对象,可以使用K-V换存;通过多个字段全文检索对象,可以通过搜索引擎存储索引;查找到的主键后再到数据库中查找全量数据。

通过SQL语法灵活的更新、查找、分析统计数据,OLTP的使用关系型数据库,OLAP的使用数据仓库,海量数据存储采用No-SQL。

多级缓存使用时,根据不同数据的特性,根据不同存储介质成本,进行区别对待,取长补短;带来的问题是数据同步问题与编程复杂度问题。

Caffeine采用Window-TinyLFU缓存淘汰算法,提供了近乎最佳的命中率。

cc13d60f84c36283714d46b3ce2123d4.png

每种存储中间件都有适用范围,根据使用场景确定如何搭配。

存储

特征

适用场景

Caffeine

JVM KV

高速读,热度集中

Redis

RPC KV

高速读、写,热度集中

ElasticSearch

FS JSON Inverted-Index

根据关键词搜索主键

MySql

DB ROW

OLTP,根据索引查找,索引未命中时大表查询有严重效率、稳定性问题

HBase

BigTable COLUMN

海量数据、对象存储、稀疏矩阵、动态列、实时报表、部分字段进行读取和聚合

Mongodb

DOC JSON

海量数据、动态列

Hive

HDFS MR WH

OLAP、海量数据、统计分析

GreenPlum

WH ROW COLUMN

OLAP、报表、AOCO-事实表、HEAP-维度表

Ignite

DataGrid KV

@see space-based pattern or cloud architecture pattern

热度:一段时间范围内,某些键被频繁访问,这些键对应的数据热度高;如果热度高的键数量少,则热度集中,反之,热度分散。

多级缓存方案搭配示例

值较小、热度集中、更新不频繁:Caffeine(JVM KV) - Redis(KV) - MySql(DB ROW)

值较大、热度集中、更新不频繁:Caffeine(JVM KV) - MySql(DB ROW)

值较小、热度分散、更新频繁:Redis(KV) - MySql(DB ROW)

值较大、热度分散:MySql(DB ROW) Cluster

基于模糊匹配:ElasticSearch(FS InvertedIndex) - MySql(DB ROW)

如果不考虑OLTP,MySql可以被No-SQL替代。

数据同步策略

定期淘汰expire

定期更新refresh

领域事件通知缓存更新refresh或驱逐evict

编程复杂度问题

多层的存储与协调由底层框架实现,采用Micro-Kernal架构,通过DIP开放能力,对外暴露Listener、Handler、Intercepter、Filter等接口。

通过元数据(Metadata)标注声明式编程,例如:JAVA的注解@Annotation。

根据典型应用场景编写最佳实践案例,有据可依。

键值命名、阈值设置等遵守统一规范。

对资源的申请建立完善的审批流程,经过专业人员分析认可后才能通过审批。

示例代码说明

代码六边形架构

9ee32a558c217b7fb4a7a0834439bf35.png

行政区划服务、仓库、缓存仓库(Caffeine JVM Cache)、DAO依赖关系

9f25f69bd1768869ef87817d2fcd6535.png

根据关键字匹配行政区划流程

4173cbcfdddf8a62a77ba64f6cc913a8.png

行政区划更新后,通知缓存驱逐流程

7e7e93d6d5178fd677d40d9c395e8905.png

Redis大Key问题排查与解决方案

大键值问题

大键值(BigKeys)两种主要使用形式:

字符串类型:它的big体现在单个value值很大,一般认为超过10KB就是bigkey。

非字符串类型:哈希、列表、集合、有序集合,它们的big体现在元素个数太多。

大键值危害:

内存空间不均匀

超时阻塞:Redis单线程的特性,操作bigkey的通常比较耗时,意味着阻塞Redis可能性越大。

网络拥塞

过期删除

迁移困难

Redis不同键值大小时压测效率差异,分别在键值大小为128字节、1KB、10KB、100KB、1MB、5MB下进行读(get)测试,其中128字节、1KB、10KB、100KB为500并发,1MB、5MB为100并发,测试环境为个人笔记本(Intel i5 2.7G, 8G DDR3, SSD)。测试结果如下:

6893146b4e01db030322f8381255bfe0.png

测试统计

键值大小

平均每次耗时(ms)

并发数

样本数

总耗时(ms)

吞吐量(次/s)

128B

23.9

500

200000

10225

19560

1KB

27.9

500

100000

7762

12883

10KB

37.5

500

100000

8763

11412

20KB

55.3

500

100000

14102

7091

30KB

65.1

500

100000

16224

6164

50KB

86

500

100000

17827

5609

100KB

145.5

500

100000

31657

3159

1MB

262.6

100

50000

140888

355

5MB

1453.8

100

20000

304725

66

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值