简介
传统的数据与缓存一站式的解决方案通常为Cache Aside模式。Cache Aside模式下，持久化层和缓存层的一致性问题主要是“双写”，即数据既在数据库中保存一份，又在缓存中保存一份，通过应用侧来维护两份数据的一致性。这种情况下会遇到很多数据一致性的问题，比如数据库和缓存的操作先后顺序、缓存是更新还是删除、数据库和缓存的操作原子性如何保证、操作失败后如何重试以及同时保证数据一致等。因此，在这种模式下大部分应用会选择牺牲一定的数据一致性。
为了面向在线业务场景构建一套完整的数据库+缓存的解决方案，实现对在线业务场景的数据访问、存储和加速，为客户提供一站式的解决方案，PolarDB MySQL版推出了数据与缓存一站式的功能。
技术原理
PolarDB MySQL版数据与缓存一站式的功能中，将Tair作为PolarDB集群的RO节点——Tair缓存节点，并向用户提供关系型数据库和缓存的一站式解决方案。
下图为数据与缓存一站式功能的技术架构图：
提供基于Tair内存引擎的能力与Redis接口语义兼容性，并将其融合到PolarDB作为RO节点支持Cache访问。
基于PolarStore的数据访问，提供高性能缓存，基于PolarDB的SCC功能（全局一致性（高性能模式）），提供了强一致性能力。
Tair Proxy和Polar Proxy融合，提供了统一的Proxy。
核心优势
数据库与缓存一致性
提供开箱即用的一站式能力，替换传统的MySQL+缓存+MQ的方案，成本更低
提供了数据强一致性，业务无需额外开发，即可解决一致性问题；同时无需自行运维额外的一致性组件，节约了MQ、同步组件等的购买和运维成本。
丰富的PolarDB产品能力：提供PolarDB+Tair的能力，同时提供关系型数据库+Key-Value等NoSQL数据库的能力，利用Tair丰富的数据结构，满足多样化的业务场景。
优异的性能：PolarDB MySQL版的Tair缓存节点拥有接近Redis的性能。
测试指标
测试指标
说明
QPS
对于Redis和PolarDB MySQL版Tair缓存节点，QPS表示每秒执行的查询数（含GET、HGET，视测试场景而定）。
对于PolarDB MySQL版的主节点和普通只读节点，QPS表示每秒执行的SELECT查询数。由于设置了每个transaction只包含1个查询，因此QPS=TPS。
Average Latency
操作的平均延迟分布，单位为毫秒（ms）。
95th Percentile Latency
95%操作的最大延迟时间，单位为毫秒（ms）。
例如：该指标的值为0.5毫秒，表示95%的请求可以在0.5毫秒内被处理。
99th Percentile Latency
99%操作的最大延迟时间，单位为毫秒（ms）。
例如：该指标的值为0.5毫秒，表示99%的请求可以在0.5毫秒内被处理。
说明
由于Sysbench的输出中只能指定一个分位点，本测试中指定为95%，因此 PolarDB MySQL版普通只读节点的测试结果中不包含该指标。
测试结果
场景一：三种节点读查询性能对比
String数据结构
value长度（字节）
节点类型
QPS（次/秒）
Average Latency（毫秒）
95th Percentile Latency（毫秒）
99th Percentile Latency（毫秒）
16
Redis读写分离版
只读节点
302444.97
0.313
0.451
0.575
PolarDB MySQL版
Tair缓存节点 （开启SCC）
201673.35
0.513
0.767
1.231
PolarDB MySQL版
Tair缓存节点 （关闭SCC）
251194.09
0.419
0.623
2.039
PolarDB MySQL版
普通只读节点
67261.98
1.43
0.94
-
128
Redis读写分离版
只读节点
293564.77
0.336
0.03
0.599
PolarDB MySQL版
Tair缓存节点 （开启SCC）
183765.10
0.530
0.831
1.799
PolarDB MySQL版
Tair缓存节点 （关闭SCC）
242174.42
0.403
0.583
1.647
PolarDB MySQL版
普通只读节点
66282.00
1.45
0.97
-
256
Redis读写分离版
只读节点
290125.14
0.340
0.487
0.567
PolarDB MySQL版
Tair缓存节点 （开启SCC）
174216.94
0.516
0.919
2.479
PolarDB MySQL版
Tair缓存节点 （关闭SCC）
239536.55
0.406
0.575
0.823
PolarDB MySQL版
普通只读节点
66575.22
1.44
0.99
-
Hash数据结构
说明
Hash数据结构场景中，数据库表的定义与String数据结构场景相同，因此PolarDB普通只读节点的读性能与上表相同，此处没有重复展示。
value长度（字节）
节点类型
QPS（次/秒）
Average Latency（毫秒）
95th Percentile Latency（毫秒）
99th Percentile Latency（毫秒）
16
Redis读写分离版
只读节点
294997.32
0.322
0.471
0.559
PolarDB MySQL版
Tair缓存节点 （开启SCC）
186980.47
0.528
0.839
1.407
PolarDB MySQL版
Tair缓存节点 （关闭SCC）
241858.95
0.406
0.583
0.935
128
Redis读写分离版
只读节点
278540.78
0.347
0.503
0.591
PolarDB MySQL版
Tair缓存节点 （开启SCC）
174051.46
0.441
0.871
1.759
PolarDB MySQL版
Tair缓存节点 （关闭SCC）
242724.15
0.402
0.575
0.887
256
Redis读写分离版
只读节点
257195.14
0.386
0.551
0.647
PolarDB MySQL版
Tair缓存节点 （开启SCC）
170178.62
0.573
0.935
2.895
PolarDB MySQL版
Tair缓存节点 （关闭SCC）
242568.36
0.402
0.583
1.031
场景二：不同缓存命中率下性能对比
命中率（%）
QPS（次/秒）
Average Latency（毫秒）
95th Percentile Latency（毫秒）
99th Percentile Latency（毫秒）
0
149090.39
0.653
0.719
1.775
50
165684.15
0.602
0.679
1.135
75
188725.06
0.505
0.623
1.287
100
215733.45
0.481
0.703
2.271
场景三：开启和关闭SCC下性能对比
说明
无论是否开启SCC，tair节点都会回放redo log更新数据，这会占据部分CPU资源。
Update/s 表示在RW节点执行随机update的速率（次/秒）
该场景下缓存命中率均为100%。
value长度（字节）
SCC状态
UPDATE（次/秒）
QPS（次/秒）
Average Latency（毫秒）
95th Percentile Latency（毫秒）
99th Percentile Latency（毫秒）
16
开启
1000
165789.91
0.544
0.967
1.567
2000
156138.20
0.627
1.143
2.287
4000
111491.45
0.797
1.391
2.495
8000
105940.97
0.959
1.607
2.623
关闭
1000
240805.05
0.405
0.575
0.887
2000
239148.58
0.412
0.583
1.095
4000
227816.33
0.420
0.575
0.951
8000
205837.92
0.474
0.791
1.791
128
开启
1000
160965.60
0.589
1.111
2.463
2000
160991.79
0.642
1.175
2.335
4000
131926.87
0.840
1.751
2.751
8000
97805
0.977
1.655
2.623
关闭
1000
243004.86
0.406
0.567
0.879
2000
230458.07
0.411
0.583
0.967
4000
234980.81
0.424
0.583
1.159
8000
190149.23
0.500
0.759
1.959
256
开启
1000
169201.09
0.587
1.063
2.399
2000
142985.23
0.629
1.111
2.127
4000
112945.09
0.817
1.383
2.383
8000
94641.14
0.989
1.591
2.591
关闭
1000
234171.71
0.419
0.607
1.255
2000
232775.40
0.418
0.583
1.055
4000
215226.14
0.447
0.599
1.007
8000
189603.56
0.520
0.775
1.823
测试结论
在主节点无写流量的情况下，三种节点的读查询QPS性能排序为：
Redis > PolarDB MySQL版Tair缓存节点（关闭SCC） > PolarDB MySQL版Tair缓存节点（开启SCC） >> PolarDB MySQL版普通只读节点
在开启SCC的情况下，命中率越高，QPS越高。当命中率为100%时，QPS比命中率为0%时约高44.7%。
在开启SCC的情况下，主节点的写压力越大，Tair缓存节点的QPS降低越明显。这是因为一方面Tair缓存节点为保证强一致性，需要等待Redo Log回放到相应点位以获取最新的值；另一方面随着写压力的增大，Tair缓存节点回放Redo Log会占用更多的CPU资源。
在关闭SCC的情况下，主节点的写压力越大，Tair缓存节点的QPS越低。但是相比于开启SCC的情况，关闭SCC时Tair缓存节点受的影响要小很多。
