【实战总结】使用Redis做模糊匹配查询

最近在做一个模糊匹配查询的需求，剖析需求本质无非就是根据入参来模糊匹配相关数据进行返回展示。

由于数据是存储在数据库的，简单实现的话可以考虑使用DB的SQL来进行模糊匹配查询，比较考量的就是如何控制你的SQL以及如果能够高效命中索引来优化SQL来实现快速查询了。

由于是全查询的业务，而且业务场景对服务响应是有一定要求的，如果简单的使用数据库恐怕后续峰值难以抗住且也会影响其他同库的读写操作，所以这次打算还是使用缓存来解决这种全查询场景。

Redis的性能非常棒，而且支持多种数据结构供开发者存储和调用，而且提供了大量API对开发非常友好，而且这些API的内部算法也是非常考究的，真的是开发利器。

1、需求背景

按照汉字以最左匹配原则进行模糊匹配，每次返回不超过固定数量的匹配词即可。

2、设计分析

首先要分析设计要解决哪些问题：

Q：高并发场景下，如何保证服务可靠且快速响应

A：使用Redis做全查询缓存，DB做数据持久化，所有请求打到缓存，保护DB；若缓存失效，把请求拦截直接返回，发送MQ异步请求DB数据更新缓存；若缓存异常，代码做兜底控制，如果可以置入动态配置来控制是否兜底查DB，极端情况下直接服务降级处理不走DB。

Q：使用Redis哪种数据结构进行存储数据？

A：首先要考虑需要返回哪些数据，且这些数据的查询可以支持模糊查询；由于需求只需要返回名称和对应ID，决定采用Hash表进行存储；且hash表支持模糊查询命令。

3、数据存储

关于Redis的命令可以参考http://doc.redisfans.com/index.html

在应用启动时，使用hmset进行批量全量缓存数据更新，这里有个细节点，由于是分布式部署，如果不加限制默认每台机器启动都会更新一遍，其实是没有必要的，可以做一个全局分布式锁进行判断和控制，这个不难实现不再细说。

HMSET key field va