分类：数据库

1 Mysql查完数据，再同步写入到Redis中
缺点1：会对接口造成延迟，因为同步写入redis本身就有延迟，并且还要做重试，如果redis写入失败，还需要重试，那就更费时间了。

缺点2：不解耦，如果redis崩了，那直接卡线程了

缺点3：如果人为该数据库，那就没法同步了， 除非再人为删除对应的Redis，但删除Redis这个过程也有个时间差

2 Mysql查完数据，通过发送MQ，在消费者线程去同步Redis
缺点1：多了层MQ，也就是会有很大的概率导致同步延迟问题.

缺点2：要对MQ的可用性做预防

缺点3：如果人为该数据库，那就没法同步了

优点1：可以大幅减少接口的延迟返回的问题

优点2：MQ本身有重试机制，无需人工去写重试代码

优点3：解耦，把查询Mysql和同步Redis完全分离，互不干扰

3 订阅Mysql的Binlog文件(可借助Canal来进行)
CanalServer会伪装成MysqlServer从库，去订阅MysqlServer主库的Binlog文件

Canal启动的时候会配置对应的消息MQ(RabbitMQ, RocketMQ, Kafka), 监听到Binlog文件有变化是，会把变化的sql语句转换成json格式，并作为消息内容发送到MQ中

项目中只要监听对应MQ，就能拿到Binlog改动的内容，Json数据中有明确的操作类型(CURD), 以及对应的数据。把对应数据同步到redis即可

缺点1：canal订阅Binlog的整个操作过程是单线程的，所以面临超高并发的情况下，性能可能不太出色。当然可以部署多个Canal 与 多个消费者，但是要注意消息重复消费问题，做好幂等性校验

优点1：即使人为改数据库，也会监听到，并且也会同步

优点2：异步同步，不会对接口返回有格外延迟

4 延迟双删
在执行修改sql之前，先将redis的数据删除

执行更新sql

延迟一段时间

再次删除redis的数据

// 延迟双删伪代码
deleteRedisCache(key); // 删除redis缓存
updateMysqlSql(obj); // 更新mysql
Thread.sleep(100); // 延迟一段时间
deleteRedisCache(key); // 再次删除该key的缓存

缺点：这个延迟时间不好把控，到底延迟多久，这个很难去评估

扩展： 如果不使用延迟双删，仅仅是delete缓存，然后改mysql数据。只有这两步会出现什么问题呢？

5. 单个请求，单线程没问题，高并发多线程下会出问题

6. 如果Thread1线程要更新数据，此时Thread1线程把redis清理了

7. 此时Thread2线程来了，但Thread1还没有更新mysql完毕

8. Thread2查询redis肯定是null，此时Thread2就要查mysql了，然后再把查到的数据写到缓存

9. 由于Thread1还没来得及修改mysql数据，所以此时Thread2查出来的数据是【旧数据】，Thread2把旧数据又写入Redis 了

10. 此时Thread3线程来了，查询Redis发现有数据，则直接拿缓存数据了，此时【Thread3查出来的是旧数据】，直接带着旧数据返回了，这就是问题所在

11. 而延迟双删的第二次删除作用就是防止Thread2把旧数据又写入了，有了延迟双删，Thread3查询Redis的时候还是null，就会从mysql 去拿最新数据了

12. 所以正常的这个延迟时间，应该是Thread2查缓存到拿mysql数据，到再保存到redis这整个时间，作为Thread1的延迟时间，但是这个Thread2这个过程的时间会受到很多因素影响，因此很难断定究竟会是多久

5 延迟双写

// 延迟双写伪代码
updateMysqlSql(obj); // 更新mysql
addRedis(key); // 再次删除该key的缓存

上述代码缺陷;

高并发下，两条线程同时执行上面代码，并对mysql 修改，且修改内容不通，可能会导致Redis与Mysql数据不一致

T1线程执行完updateMysqlSql，释放了行锁，此时T2线程再执行updateMysqlSql 与 addRedis， 最后T1执行addRedis，这种情况会导致数据库改成了T2线程的数据，但Redis却是T1线程的数据

优化

// 完美延迟双写伪代码
开启事务
updateMysqlSql(obj); // 更新mysql
addRedis(key); // 再次删除该key的缓存
提交事务

上述代码改正：

把两句代码放到一个事务里面，只有T1执行完Mysql 与 Redis的时候，T2才能开始执行，就可以保证数据一致性。推荐使用分布式锁

双写缺点：Mysql 与 Redis是单线程的。性能方面不行，因此不推荐使用

6 总结
推荐使用Canal的方式，进行异步同步。其次是MQ方式

本文出自：https://blog.csdn.net/qq_37284798/article/details/129518953

MySQL的加解密及压缩函数
许多加密和压缩函数返回结果可能包含任意字节值的字符串。如果要存储这些结果，请使用具有VARBINARY或BLOB二进制字符串数据类型的列。这避免了删除尾随空格或转换字符集可能改变数据值的潜在问题，例如使用非二进制字符串数据类型（CHAR、VARCHAR、TEXT）时可能发生的问题。

MySQL加解密函数
MySQL自带的加解密函数主要有以下：

一些加密函数返回 ASCII 字符字符串：MD5（）、PASSWORD（）、SHA（）、SHA1（）、SHA2（）。它们的返回值为具有由character_set_connection和collation_connection系统确定的字符集和排序规则的字符串 变量。这是一个非二进制字符串，除非字符集为 。

如果应用程序存储来自返回十六进制字符串的函数（如 MD5（） 或 SHA1（） 的值） 数字，可以通过以下方式获得更有效的存储和比较 使用 UNHEX（） 将十六进制表示形式转换为二进制，并将结果存储在 BINARY（N） 列中。

将十六进制字符串存储在 CHAR 列中的大小损失至少为两倍， 如果值存储在使用该字符集的列中，则最多 4 次（其中每个字符使用 <> 字节）。存储字符串也会导致比较速度变慢 因为值较大且需要采用字符集 将排序规则考虑在内。

ENCODE()、DECODE()

已在5.7.2版本弃用，目前仍可用，但将在后续版本中删除。

DES_ENCRYPT()、DES_DECRYPT()

AES_ENCRYPT()加密与AES_DECRYPT()解密
AES高级加密标准（英语：Advanced Encryption Standard，缩写：AES），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。

AES_ENCRYPT和AES_DECRYPT在MySQL中是进行加密了，如果你需要对MySQL某些字段进行加解密的话，使用MySQL的加解密函数可能比程序中处理更方便.

AES_ENCRYPT(‘密码’,‘钥匙’)
AES_DECRYPT(表的字段名字,‘钥匙’)
这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。

严格地说，AES和Rijndael加密法并不完全一样（虽然在实际应用中二者可以互换），因为Rijndael加密法可以支持更大范围的区块和密钥长度：AES的区块长度固定为128 比特，密钥长度则可以是128，192或256比特；而Rijndael使用的密钥和区块长度可以是32位的整数倍，以128位为下限，256比特为上限。包括AES-ECB,AES-CBC,AES-CTR,AES-OFB,AES-CFB

函数参数(MySQL版本小于等于5.7.6)
AES_ENCRYPT(str,key_str)，其中str为待加密字符串，key_str为秘钥

AES_DECRYPT(crypt_str,key_str)，其中crypt_str为已加密的二进制串，key_str为秘钥

已在5.7.6版本弃用，目前仍可用，但将在后续版本中删除。

AES_ENCRYPT()、AES_DECRYPT()

推荐使用这对加解密函数。aes_encrypt()和aes_decrypt()使用官方的aes（高级加密标准）算法（以前称为“rijndael”）实现数据的加密和解密。

加密后的二进制串长度可以通过下面公式计算：

16 * (trunc(string_length / 16) + 1)

函数参数(MySQL版本大于等于5.7.6)
函数参数
AES_ENCRYPT(str,key_str[,init_vector])，其中str为待加密字符串，key_str为秘钥，其中init_vector根据选择不同的块加密模式为可选项

AES_DECRYPT(crypt_str,key_str[,init_vector])，其中crypt_str为已加密的二进制串，key_str为秘钥，其中init_vector根据选择不同的块加密模式为可选项

st和key_str参数可以是任何长度，init_vector参数不得小于16个字符。可以通过block_encryption_mode参数，控制块加密模式，默认值为：aes-128-ecb。可配置的形式为：aes-keylen–mode。

keylen可配置为128, 192, 256

mode可配置为ECB, CBC, CFB1, CFB8, CFB128, OFB。

下表展示了不同mode是否需要init_vector参数。

默认的ECB模式不需要init_vector参数，用法与5.7.4以前相同。

修改块加密模式：

set block_encryption_mode=’aes-256-cbc’;

查看对应的加解密模式

show variables like ‘block%;

block_encryption_mode
此变量控制的块加密模式，基于块的算法，例如 AES。它会影响 AES_ENCRYPT（） 和 AES_DECRYPT（） 的加密。

block_encryption_mode需要格式中的值，其中 Keylen是关键位和模式的长度为加密模式。该值不区分大小写。允许的键值为 128、192 和 256. 允许的加密模式取决于 MySQL 是否 使用 OpenSSL 或 yaSSL 编译：aes-keylen-mode。

例如，此语句会导致 AES 加密 使用 256 位密钥长度和 CBC 模式的函数：

SET block_encryption_mode = ‘aes-256-cbc’;

尝试将block_encryption_mode设置为包含不受支持的密钥长度或模式的值不支持SSL库。

AES_ENCRYPT(str,key_str[,init_vector][,kdf_name][,salt][,info | iterations])

AES_ENCRYPT加密 字符串 str 使用键字符串 key_str，并返回二进制文件 包含加密输出的字符串。AES_DECRYPT（） 使用密钥字符串key_str解密加密字符串crypt_str，并返回原始 纯文本字符串。如果任一函数参数为 ，则该函数返回 。如果 AES_DECRYPT检测到无效 数据或填充不正确，它将返回 . 但是，AES_DECRYPT（） 有可能 返回非值（可能是垃圾） 如果输入数据或键无效。NULLNULLNULLNULL

使用AES_DECRYPT（）的语句对于基于语句的复制。

AES_DECRYPT(crypt_str,key_str[,init_vector][,kdf_name][,salt][,info | iterations])

AES_ENCRYPT（） 和 AES_DECRYPT（） 允许控制 块加密模式。block_encryption_mode系统 变量控制基于块的加密模式 算法。其默认值为 ，表示加密 使用 128 位的密钥长度和 ECB 模式。有关说明 此变量的允许值，请参见第 5.1.7 节 “服务器系统变量”。这 可选init_vector参数为 用于为块加密提供初始化向量 需要它的模式。aes-128-ecb

本文出自：https://blog.csdn.net/l569590478/article/details/132187930