某电商商品搜索系统架构设计

对于电商系统来说，商品搜索是其核心功能之一，如何能保证在海量的数据中，能低延时的搜索到关心的商品信息直接影响到用户的使用体验，在商品搜索中，如根据用户画像定向的做推荐，或是基于位置信息如美团O2O类搜索，这些个性化搜索是关系型数据库无法完成的，这时候搜索引擎ElasticSearch+Redis就能发挥关键作用。

ElasticSearch数据同步

如果将MySQL的数据同步到ElasticSearch引擎中，最简单的方式就是在操作DB之后直接更新到ES索引中，但是这种方式与业务代码的耦合程度太高，维护成本较高。这里我们使用阿里巴巴开源中间件Canal帮我们完成数据同步。Canal是典型的CS架构，Server端会伪装成MySQL slave节点，通过监听MySQL master节点的binlong日志，会将binlog日志发送到Canal Clinet端，Client在将数据写入到ElasticSearch中，针对常见的写入端，Canal官方已经提供了Adapter可以开箱即用。但是在生产中可能MySQL与ES索引并不是一一对于了，这时候就需要我们二次开发，预留扩展接口让用户自行开发。

在海量的数据场景下，单台ElasticSearch无法存储海量数据，也无法做到高可用，这时候就需要搭建高可用架构。我们需要对ES进行分片，分片数量需要提前预估，因为索引是不可更改，一旦数据哈希到某台机器的索引上，便不太容易在扩容切割。

既然是高可用架构，我们的ES实例肯定需要部署在多台机器上，主分片和副分片不要在一台机器上，这样既然某台服务器宕机，其他机上的副分片会立即升级为主分片。上图所示，有三台物理机器，四个主分片和四个副分片，均匀分布在三台机器上，任何一台机器宕机，对应机器上的分片都能找到副分片。当然我们建议至少是一个主分片对应两个以上的基数副分片。

Redis数据如何同步

Redis没有必要存储MySQL的所有数据，我们只要将热点数据存储到Redis即可，这里我们使用的是JetCache框架帮我们完成同步，JetCache是通过AOP将数据持久化到Redis中的，主要我们需要设置过期时间，以及更新MySQL数据的时候及时失效点缓存。如何使用JetCache请参考官网JetCache，如何保证缓存数据一致性请参考缓存一致性方案。

既然ES都已经做集群了，那么Redis单机版也是无法做到高可用的，Redis集群虽然在一定程度上能满足高可用，但是无法达到数据无限水平扩容目前，因为我们的数据量会越来越多，单个节点无法存储所有数据，这时候我们使用的是Redis cluster模式。

在cluster模式下，会有多个master节点，这些节点会平分16384个槽点，数据在写入的时候，会根据key散列到其中的一个槽点，在每个Master节点下都会连接多个slave节点，master节点宕机salve节点立即成为主节点承担读写任务。

有了ES为什么还需要Redis

职责不太，ES比较适合做聚合搜索，一般在买家首页，根据用户的搜索条件、位置、用户画像等条件搜索，他搜索的是一批数据，而Reids由于它的存储结果是K-V形式，这就觉得了他只适合根据主键制作搜索，比如用户在商城首页搜索到商品，需要点击商品详情，这时候就从Redis中取数据。