极限网关在好未来的最佳实践案例，轻松扛住日增百 TB 数据的流量，助力 ES 从物理机到云原生架构的改造，实现了流控、请求分析、安全管理、无缝迁移等场景。一次完美的客户体验~

背景

物理机架构时代

2022 年，好未来整个日志 Elasticsearch 拥有数十套服务集群，几百台物理机。这么多台机器耗费成本非常高，而且还要花费很大精力去维护。在人力资源有限情况下，存在非常多的弊端，运行成本高，不仅是机器折旧还有机柜等费用。

流量特征

这是来自某个业务线，如下图 1，真实流量，潮汐性非常明显。好未来有很多条业务线，几乎跟这个趋势都一致的，除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期 CPU、内存资源是可以消耗很高；低峰期资源使用量非常低，由于是物理架构，这些资源无法给其他业务线共享。

降本增效-容器化改造原动力

日志服务对成本的空前的压力促使我们推进 Elasticsearch 进行架构改造；如何改造，改造成什么样子，这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是 K8S，我们开始对 Elasticsearch 改造成能在 K8S 上运行进行探索，从而提升 CPU、内存利用率。

物理机时代，没办法把资源动态的扩缩，动态调配，资源隔离，单靠人力操作调度成本太高，几乎无法完成；集群对内存资源需求要比 CPU 资源大很多，由于机器型号配置是固定的，无法“定制”，这也会导致成本居高不下。所以，无论从那个方面来讲，容器化优势非常明显，既能够优化成本，也能够降低运维复杂度。

ES 容器化改造

进行架构升级重点难点- API 服务

改造过程，我们遇到了很多问题，比如容器 ES 版本和物理机 ES 版本不一致，如何让 ES API 能够兼容不同的 ES 版本，由于版本的不兼容，导致无法直接使用原有的 tribenode 进行服务，怎么提供一个高可用的 Elasticsearch API 服务。我们考虑到多个方面，比如使用官方推荐的 proxy 模式、第三方服务等进行选择，经过多方面对比，选择了极限网关 进行 tribenode 替换。

原始 ES API 服务痛点

• API 访问没有流量控制
• 可观测性差，而且稳定性一般
• 版本兼容性差

物理机时代 API 架构

在物理机时代 ES 集群，API 架构如图 2，可以明显看到 tribe node 对所有 ES 集群的“侵入性”是非常大的，这就带来了很多问题，比较严重的就是单个集群对 ES tribenode 的影响和版本升级带来的不兼容问题。

混合时代 API 架构

通过图 3，我们可以看到，极限网关对于版本兼容性很好，能够适配不同的版本。因此，最终选择极限网关作为下一代 ES API 服务方。

里程碑：全部 ES 集群容器化

在 2023 年 3 月份，通过 Elastic 官方 ECK 模式，完成全部日志 ES 集群容器化改造，拥有数百节点，1PB+ 数据存储，每日新增数据 100T 左右。紧接着，除了日志服务外，同时支持了好未来多条业务线。

极限网关实践

下面主要讲述了，为什么选择极限网关，以及极限网关在好未来落地、应用这些内容。

为什么选择极限网关？

学习成本低

我们可以从文档中看到极限网关，其架构简洁，语法简单，直观易懂。学习成本比较低，上手非常快，对新手友好。

性能强悍

经过压测，发现极限网关速度非常快，且针对 Elasticsearch 做了非常细致的优化，能成倍提升写入和查询的速度。

安全性高

支持多种认证方式，最简单的账号密码认证，可以给自定义多个账户密码，大大简化了 Elasticsearch 的安全设置，同时，还可以支持 LDAP 安全验证。

跨版本支持

我们容器化改造过程需要兼容不同版本的 Elasticsrearch，极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理，能够让业务代码无缝的进行适配，后端 Elasticsearch 集群版本升级能够做到无缝过渡，降低版本升级和数据迁移的复杂度，非常匹配我们的业务场景。

灵活可扩展

可灵活对每个请求进行干预和路由，支持路由的智能学习，内置丰富的过滤器，通过配置动态修改每个请求的处理逻辑，也支持通过插件来进行扩展，满足我们对流量的控制，尤其是限流、用户、IP 等这些功能非常实用。

启用安全策略-为 API 服务保驾护航

痛点

在升级之前使用 tribe 作为 API 服务提供后端，几乎相当于裸奔，没有任何认证策略；另外，tribe 本身的稳定性也有问题，官方在新版本逐渐废弃这种 CCS（跨集群搜索），期间出现多次服务崩溃。

极限网关解决问题

极限网关通过，“basic_auth” 插件，提供最基本的安全校验，使用起来非常方便；同时，极限网关提供 LDAP 插件，可以接入公共的 LDAP 服务，对所有的访问用户进行校验，安全策略对所有的用户生效，不用担心因为 IP 问题泄漏数据等。

强大的过滤功能

在使用 ES 集群过程中，许多场景，需要对请求进行控制、限制等操作。在这方便，感受到了极限网关强大的产品力。比如下面的两个场景

对异常流量进行限流

• 支持对 IP 限流
• 支持对 hostname 限流
• 支持 header 限流

对异常用户进行封禁

当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候，request_user_filter 过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单，只需要 request_user_filter 这一个过滤器。

- request_user_filter:
    include:
        - "elastic"
    exclude：
        - "Ryan"

总结来讲，主要有这些方面的功能：

优秀的可观测性

痛点

改造前经常为看不到直观的数据指标感到头疼，查看指标需要多个地方同时打开，去筛选，查找，非常繁琐，付出的成本非常大。为此，大家都再考虑如何优化这种情况，无奈优先级比较低，一直没有真正的投入时间去优化这块。

完美解决

使用了极限网关，通过收集请求日志，非常清晰的收集到想要的数据，具体如下：

• 总体方面：
  • 流量曲线
  • 状态码占比
  • 缓存统计
  • 每台网关请求流量
• 细节方面：
  • 打印每次请求语句
  • 可以查看请求到具体 ES 节点流量
  • 可以查看过滤器的列表

通过下图，我们可以从管理视角直观的看到各种信息，这对于管理员来讲，省时省力，方便快捷。

意外收获：无缝迁移业务 Elasticsearch 上云

由于前期日志业务上云，受到非常好的反馈，多个业务线期望能够上云上服务，达到降本增效的目的。

支持双写

数据可以通过极限网关同时写入两个 ES 集群，能够保障数据完全一致，安全可靠。

无缝切换

切换很丝滑，影响非常小，能够让外界几乎感受不到服务波动。

通过使用极限网关，自建 ES 集群可以无缝的迁移上云，在整个迁移的过程中，两套集群通过网关进行了解耦，在迁移的过程中还能实现版本的无缝升级，极大降低了迁移成本，提高迁移效率，多次验证服务稳定可靠。

极限网关流量概览

这是其中一套极限网关的流量统计。用这部分数据进行巡检，一目了然，做到全局的掌控，提高感知力度。

极限网关使用总结

极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处：

1. 可观测性好：极限网关可以动态的对 Elasticsearch 运行过程中请求进行拦截和分析，通过指标和日志来了解集群运行状态，这些指标可以用于提升性能和业务优化。
2. 增强安全性：包含先进的安全机制，如 basicauth、LDAP 等支持，保护用户数据不受未授权访问和各种网络威胁的侵害。
3. 高稳定性：通过冗余设计和故障转移机制，极限网关能够确保网络服务的高可用性，即使在某些组件发生故障时也能保持服务不中断，单版本最长服务超过 15 个月。
4. 易于管理：通过提供 INFINI Console 简洁直观的管理界面，让用户能够轻松配置和监控网络状态，提升管理效率。
5. 客户支持：良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题，提供专业的技术指导。

综上所述，极限网关为用户提供了一个高速、安全、稳定且易于管理的 ES 网关，适合对网络性能有较高要求的个人和企业用户。

未来规划

第一阶段，完成了日志 ES 集群，所有集群的容器化改造，合并，成功的把成本降低了 60%以上。这期间积累了丰富容器化经验，为业务 ES 集群上容器做了良好的铺垫；成本优势和运维优势吸引越来越多的业务接入到容器化 ES 集群。

提升 ES 集群效能--新技术应用&&版本升级

• 极限科技官方推荐的 Easysearch 在压缩率，查询速度等等方面有很多的优势，通过长时间的测试稳定性，新特性，对比云原生的 ES 集群，根据测试结果，给“客户”提供多种选择，这也是工作重点之一。
• 我们当前使用的 ES 版本是 6.8，已经远远落后于官方版本，今年我们计划在选择合适的集群升级 ES 版本，拥抱更多官方提供的特性。

混合（多）云架构支持

随着越来越多的 ES 集群在机房的 K8S 集群部署，这里资源出现了紧张局面。 我们尝试在云上部署自建 ES 集群，弥补机房资源有限，无法大规模扩容，同时能够支持多活场景，满足更多客户的不同需求。混合云主要实现以下几种能力：

1、扩缩容：满足不同业务灵活适配

混合（多）云部署，可以让负载内部私有云 ES，同时部署到公有云，提升扩展 IT 基础设施不仅局限于 CPU、内存，还有存储。比如某一个业务要做活动，预估流量“大爆发”，需要提前准备大规模资源，在机房内根本来不及采购扩容支持，然而在公有云上就能很方便扩容、缩容。在云上搭建 ES 集群，设置满足需求的数量、容量、配置，配合极限网关路由策略，精准的把控流量流向。

2、灾备：紧急情况快速部署，恢复 ES 集群读写

当机房级别大规模故障，部分业务实现了多活，单一的机房故障不会影响其服务能力，而此时比如日志查看等仍有需求，为了满足这部分“客户”需求，可以在云上 K8S 集群，快速搭建 ES 集群，恢复日志读写功能。

参考文档：

• https://infinilabs.cn/docs/latest/gateway
• https://www.elastic.co/guide/en/cloud-on-K8S/current/K8S-overview.html

作者：张华勋，前新浪 CDN 研发，工作主要涉及 Mysql、MongoDB、Redis、Elasticsearch、流量调度等组件和系统，以及运维自动化、平台化等工作。现就职于好未来。

关于好未来

好未来（NYSE：TAL）是一家以内容能力与科技能力为基础，以科教、科创、科普为战略方向，助力人的终身成长，并持续探索创新的科技公司。 好未来的前身学而思成立于 2003 年，2010 年在美国纽交所正式挂牌交易。好未来以“爱与科技助力终身成长”为使命，致力成为持续创新的组织。更多参见：https://www.100tal.com/

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：https://www.infinilabs.cn

INFINI Labs 产品又更新啦~，包括 Easysearch v1.8.2、Gateway、Console、Agent、Loadgen v1.26.0。本次各产品更新了很多亮点功能，如 Easysearch 优化 CCR 同步性能；Gateway 增加了 HTTP 请求动态域名路由功能，移除了安全相关的 Filter，进一步提升 Gateway 稳定性；Console 修复了多个已知问题，如当文档数过亿时单位换算错误，修复了因采集延迟导致指标图表显示异常，修复了多行查询中包含 SQL 查询异常等问题。欢迎大家下载体验。

以下是本次更新的详细说明。

INFINI Easysearch v1.8.2

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎，核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。

Easysearch 本次更新如下：

Bug fix

• 修复 source_reuse 与 object 字段为 enable: false 时的冲突

Improvements

• 升级部分依赖包版本，Commons-collections to 3.2.2, Snakeyaml to 2.0
• 优化 CCR 同步性能及调整 CCR 全局配置参数
• 优化插件配置命名，去除"plugins."
• 优化配置文件目录获取命名

INFINI Console v1.26.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管， 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验： http://demo.infini.cloud (用户名/密码：readonly/readonly)。

Console 本次更新如下：

Bug fix

• 修复监控数据布局
• 修复命令存储权限
• 修复多行请求包含 SQL 语法
• 修复文档数过亿时换算错误
• 修复导入低版本 v1.6.0 告警规则缺少字段问题
• 修复当 buck_size 小于 60 秒时，因指标采集延迟导致指标显示异常问题

INFINI Gateway v1.26.0

INFINI Gateway 是一个面向搜索场景的高性能数据网关，所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

Gateway 本次更新如下：

Improvements

• feat: add wildcard_domain filter
• chore: remove security filter and translog_viewer

INFINI Framework

INFINI Framework 是 INFINI Labs 各产品依赖的内部核心公共代码库。

Framework 本次更新如下：

Improvements

• feat: support dynamic app setting
• feat: add cluster settings query args
• feat: add gateway config
• feat: add http interceptor
• feat: return host info in info api
• feat: add util to convert string to float
• feat: use common app setting api to instead of auth setting api
• feat: crontab task support multi crontab expression
• fix: skip submit empty bulk requests
• feat: support ccr api
• fix: get latest offset should compare segment first
• fix: wrong use of zstd with vfs
• fix: prevent close closed channel
• fix: panic on error while saving keystore

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

• 下载地址： https://www.infinilabs.cn/download

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

欢迎加入 Discord 聊天室：https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群一起讨论交流。

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：https://www.infinilabs.cn

RediSearch是一个Redis模块，为Redis提供查询、二次索引和全文搜索。要使用RediSearch，首先要在Redis数据上声明索引。然后可以使用重新搜索查询语言来查询该数据。

RedSearch使用压缩的反向索引进行快速索引，占用内存少。RedSearch索引通过提供精确的短语匹配、模糊搜索和数字过滤等功能增强了

实现特性

• 基于文档的多个字段全文索引
• 高性能增量索引
• 文档排序（由用户在索引时手动提供）
• 在子查询之间使用 AND 或 NOT 操作符的复杂布尔查询
• 可选的查询子句
• 基于前缀的搜索
• 支持字段权重设置
• 自动完成建议（带有模糊前缀建议）
• 精确的短语搜索
• 在许多语言中基于词干分析的查询扩展
• 支持用于查询扩展和评分的自定义函数
• 将搜索限制到特定的文档字段
• 数字过滤器和范围
• 使用 Redis 自己的地理命令进行地理过滤
• Unicode 支持（需要 UTF-8 字符集）
• 检索完整的文档内容或只是ID 的检索
• 支持文档删除和更新与索引垃圾收集
• 支持部分更新和条件文档更新

对比 Elasticsearch

如下图所示，RediSearch 构建索引的时间为 221 秒，而 Elasticsearch 为 349 秒，快了 58%。

索引构建测试

我们模拟了一个多租户电子商务应用程序，其中每个租户代表一个产品类别并维护自己的索引。对于此基准测试，我们构建了 50K 个索引（或产品），每个索引最多存储 500 个文档（或项目），总共 2500 万个文档。

RediSearch 仅用了 201 秒就构建了索引，平均每秒运行 125K 个索引。然而，Elasticsearch 在 921 个索引后崩溃了，显然它不是为应对这种负载而设计的。

查询性能测试

一旦数据集被索引，我们就使用在专用负载生成器服务器上运行的 32 个客户端启动两个单词的搜索查询。如下图所示，RediSearch 吞吐量达到了 12.5K 操作/秒，而 Elasticsearch 为 3.1K 操作/秒，速度提高了 4 倍。

此外，RediSearch 延迟稍好一些，平均为 8 毫秒，而 Elasticsearch 为 10 毫秒。

安装

安装目前分为源码和docker安装两种方式。

源码安装

git clone https://github.com/RediSearch/RediSearch.git
cd RediSearch # 进入模块目录
make setup
make install

docker安装

note: RediSearch的安装比较复杂原包无法进行编译操作所以我们使用docker安装
docker run -p 6379:6379 redislabs/redisearch:latest

判断是否安装成功

127.0.0.1:0>module list
1) 1) "name"
   2) "ReJSON"
   3) "ver"
   4) "20007"

2) 1) "name"
   2) "search"
   3) "ver"
   4) "20209"

返回数组存在“ft”或 “search”(不同版本)，表明 RediSearch 模块已经成功加载。

命令行操作

1、创建

1.1 创建索引

创建索引不妨想象成创建表结构，表一般基本属性有表名、字段和字段类别等，所以我们可以考虑将索引名代表表名，字段代表字段，属性即表示属性。

xxx.xxx.xxx.xxx:0>ft.create "student" schema "name" text weight 5.0 "sex" text "desc" text "class" tag
"OK"

student 表示索引名，name、sex、desc表示字段，text表示类型（这样表示只是为了便于理解）

“weight”为权重，默认值为 1.0

type student
"none"

我们创建的索引redis是不认识的，这证明使用的是插件。

1.2 创建文档

创建文档上下文的过程不妨想想成向表中插入数据，这里请注意字段名可以使用双引号但切记一定要用英文，这里之所以着重提出是因为有些编译器中文双引号和英文双引号用肉眼实在难以辨认否则会出现 “Fields must be specified in FIELD VALUE pairs”（其实是将“ 当作内容处理了以至于缺少了字段）

ft.add student 001 1.0 language "chinese" fields name "张三" sex "男" desc "这是一个学生" class "一班"
"OK"

其中001为文档ID,"1.0"为评分缺少此值会报"Could not parse document score"异常，language 指明使用的语言默认是英文编码 如果没有此标记存储是没有问题的但不可以通过中文字符查询

1.3 查询

1.3.1 基本查询

1.3.1.1 全量查询

xxx.xxx.xxx.xxx:0>FT.SEARCH student * SORTBY sex desc RETURN 3 name sex desc
1) "2"
2) "001"
3) 1) "name"
   2) "张三"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"

4) "002"
5) 1) "name"
   2) "张三"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"

1.3.1.2 匹配查询

xxx.xxx.xxx.xxx:0>ft.search student "张三" limit 0 10 RETURN 3 name sex desc
1) "2"
2) "001"
3) 1) "name"
   2) "张三"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"

4) "002"
5) 1) "name"
   2) "张三"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"

limit 与mysql相识主要用于分页，此处是全量匹配，如果没有设置language “chinese” 此处查询为0，

1.3.2 模糊匹配

1.3.2.1 后置匹配

ft.search student "李*"  SORTBY sex desc RETURN 3 name sex desc
1) "1"
2) "003"
3) 1) "name"
   2) "李四"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"

1.3.2.2 模糊搜索

xxx.xxx.xxx.xxx:0>FT.SEARCH beers "%%张店%%"
1) "1"
2) "beer:1"
3) 1) "name"
  2) "集团本部已发布【文明就餐公约】，2号楼办公人员午餐的就餐时间是11:45~13:00，现经行政服务部进行抽查，发现我们部门有员工违规就餐现象。请大家务必遵守，相互转告，对于外地回到集团办公的同事，亦请遵守，谢谢！"
   3) "org"
   4) "山东省淄博市张店区"
   5) "school"
   6) "山东理工大学"

别高兴太早全量模糊匹配是由很大限制的，他基于Levenshtein距离（LD）进行模糊匹配。术语的模糊匹配是通过在术语周围加“%”来实现的，模糊匹配的最大LD为3，确切的说这只是一种相识度查询，并非一般意义上的模糊搜索，但是如果仔细观察会发现通过精确匹配时不仅能够将完整value值查询出来而且还查询出其他处于文档某个位置的key请看官方提供的一个例子：

FT.CREATE idx SCHEMA txt TEXT
FT.ADD idx docCn 1.0 LANGUAGE chinese FIELDS txt

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。

由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

FT.CREATE idx SCHEMA txt TEXT
FT.ADD idx docCn 1.0 LANGUAGE chinese FIELDS txt "Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。[8]"
FT.SEARCH idx "数据" LANGUAGE chinese HIGHLIGHT SUMMARIZE
# Outputs:
# <b>数据</b>?... <b>数据</b>进行写操作。由于完全实现了发布... <b>数据</b>冗余很有帮助。[8...

之所以会出现这样的效果是因为redisearch对文本进行了分词，其使用的工具是friso相比es的ik还是弱一些前者主要是对中文分词，体积小可移植性强。

从而我们可以结合后后置匹配算法

xxx.xxx.xxx.xxx:0>FT.SEARCH idx "数*" LANGUAGE chinese HIGHLIGHT
1) "1"
2) "docCn"
3) 1) "txt"
  2) "Redis支持主从同步。<b>数据</b>可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对<b>数据</b>进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和<b>数据</b>冗余很有帮助。[8]"

或者结合Levenshtein算法这样基本上能够满足业务查询需求

xxx.xxx.xxx.xxx:0>FT.SEARCH idx "%%单的树%%" LANGUAGE chinese HIGHLIGHT
1) "1"
2) "docCn"
3) 1) "txt"
  2) "Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层<b>树</b>复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步<b>树</b>时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。[8]"

1.3.2.3 字段查询

通过字段查询也可以实现模糊搜索，直接给例子，后面跟着官网上给的sql 和 redisearch的对照表

ft.search student *
1) "2"
2) "doudou"
3) 1) "name"
   2) "豆豆"
   3) "jtzz"
   4) "“检索”是很多产品中"
   5) "phone"
   6) "18563717107"

4) "ttao"
5) 1) "name"
   2) "姚元涛"
   3) "jtzz"
   4) "一个生病的人只"
   5) "phone"
   6) "18563717107"

ft.search student '@phone:185* @name:豆豆'
1) "1"
2) "doudou"
3) 1) "name"
   2) "豆豆"
   3) "jtzz"
   4) "“检索”是很多产品中"
   5) "phone"
   6) "18563717107"

1.4 删除

1.4.1 删除文档

xxx.xxx.xxx.xxx:0>ft.del student 002
"1"

1.4.3 删除索引

xxx.xxx.xxx.xxx:0>ft.drop student
"OK"

1.5 查看

1.5.1 查看所有索引

xxx.xxx.xxx.xxx:0>FT._LIST
1) "student1"
2) "ttao"
3) "idx"
4) "student"
5) "myidx"
6) "123"
7) "myIndex"
8) "testung"
9) "student2"

1.5.2 查看索引文档中的数据

1.5.2.1 获取单条数据

xxx.xxx.xxx.xxx:0>ft.get student 001
1) "name"
2) "张三"
3) "sex"
4) "男"
5) "desc"
6) "这是一个学生"
7) "class"
8) "一班"

1.5.2.2 获取多条数据

xxx.xxx.xxx.xxx:0>ft.mget student 001 002
1) 1) "name"
   2) "张三"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"
   7) "class"
   8) "一班"

2) 1) "name"
   2) "张三"
   3) "sex"
   4) "男"
   5) "desc"
   6) "这是一个学生"
   7) "class"
   8) "一班"

1.6 索引别名操作

1.6.1 添加别名

123.232.112.84:0>FT.ALIASADD xs student
"OK"

给索引student起个xs的别名，一个索引可以起多个别名

1.6.2 修改别名

1.6.3 删除别名

123.232.112.84:0>FT.ALIASDEL xs 
"OK"

作者：架构师公众号

来源：https://mp.weixin.qq.com/s/TmCXx3rLjLPggvOFjGqS9w

版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!