本文只针对笔者自己的项目情况，不使用redis，而且使用更专业的消息队列服务器的存在有更充分的理由。

选择的原因

性能天花板

从树莓派到志强，redis是所有mq服务器的天花板。
自己手撸的简单hash map查询 业务添加一些 都比不过redis，而且在大量数据的情况下，查询和操作速度更是直线下滑。想做到极致的性能优化需要大量繁重工作，不如直接拿来就用

简单灵活的高可用性集群

哨兵模式和主从模式也不是不能用。
cluster 虽然必须要最少3主3从才能实现高可用性，但是很容易满足。3台云服务器即可 互为主从 并集群，可以在线扩容，在线收缩，简单灵活可靠。

低流量消耗的轻量化协议

redis 是基于tcp的简单文本协议，没有协议头，没有校验码，没有封装，每一个字节都是有效必须的数据，大大节省服务器带宽资源

活跃的老项目良好的向上兼容

redis至今依旧维持较为频繁的功能和性能更新

免中间件

1、工作量小 服务器上不需要再运行太多程序，开发工作小很多（在大并发环境一个中间件 真的很需要时间调试优化）
2、节省服务器开支

性能下限高

团队里面的实习生，只要不让他碰redis扩展module的代码，再烂的代码也不会影响整体运行

不用更专业的mq的原因

现有的主流mq服务， 性能都低于redis,在集群扩展上也都远远不如redis灵活和高效。
部分mq自带的消息持久化储存 性能更是一般，外部储存方式 多了一层转换。很多mq可能已经很轻量，但是相对 redis 还是差了一些。 Kafka RocketMQ Apollo ZeroMQ ActiveMQ RabbitMQ emqx Mosquitto 情况差不多，不展开细说
集群方面，要么死板复杂不能热扩容收缩，要么集群后单机性能会掉

不使用 loTDB的原因

没有看到loTDB的压测数据，自己简单测试过后性能不理想

不自己开发私有协议的原因

私有协议 可以灵活使用 tcp/udp 包括上层websocket。但是集群部署 还有大量map的操作 开发工作量比较大。
另外 golang在 大并发情况下 资源占用要比C高很多，引入epoll可以降低一些，但是开发工作量还是不低。

物联网设备通讯要求

基本

包括多数物联网设备的的要求 我手上的项目情况有以下要求：

• 低成本、可快速扩展、高可用性集群
• 部分功能要求消息必须送达：例如 报警信息
• 部分消息 要求 只可以送达1次，不可重复送达：例如 提醒消息
• 部分数据允许少量丢失: 例如设备实时采集的数据
• 设备24小时开机，不停上报数据。对服务器处理和记录能力有一定要求（最主要是服务器成本要低）
• 设备离线通知和报警
• 设备和用户app可以直接进行通讯，当然 这里指的还是服务器转发消息
• qps的严格限制，防止服务器被拉垮
• 部分功能需要 tls加密通讯
• 消息需要选择性的持久化和转存

tcp和udp

国内环境下 部分地区部分时段udp 丢包严重。另外udp每次都需要带一定字数的token信息 虽然减少了握手环节，但是对于 少量频繁的数据通讯 就会明显增加服务器流量开支
ws协议，有更好，没有可以接受，毕竟物联网设备直接tcp udp是没问题的。

自定义协议和现有协议的选择

自定义协议tcp/udp 自然是更好，但是之前的项目开发经验让我明白 还是要权衡利弊一下。

数据的序列化和反序列化

考虑到服务器资源的占用，json 肯定是最不可取的。msgpack反序列化性能还可以，但是比json并不能降低太多带宽。 所以开发阶段用json或者msgpack,后期还是要换成protobuf。

用redis实现上面的功能的逐一说明

因为redis 本身不适合作为面向用户的消息队列服务，所以有一些问题需要额外处理。

• 使用redis6.0 以后的tls 解决加密通讯
• 务必使用redis7.0以后版本的 acl 精确控制到key和指令
• 使用stream 处理 必到达的消息 和 之发送一次的消息
• 使用sub 处理一次性不需要储存 可以容许丢失的消息
• redis开启数据持久化，但是后端需要定期把历史消息转储存到sql，防止redis内的历史消息占用内存多大
• 集群 cluster 解决高可用性和灵活扩展性
• redis 集群客户端 在物联网设备 和 app端 socket 手撸。使用{key}标识符，把单一个物联网设备的数据固定到一个节点上即可，然后客户端自动从任意一个节点得到负责的节点地址。
• 设备离线通知： 后端程序 连到redis 定时扫描 客户端连接信息，找出应在线但是未连接的客户端

关于权限控制和防恶意用户

• key访问权限和指令限制：使用redis7.0以后版本的 acl 限制 物联网客户端可用指令和可写key
• 后端程序 通过扫描redis客户端信息，拉黑频繁多次连接的用户
• key 内容大小限制：简单的方案 依旧是后端程序定期扫描bigkey。我的方案，自己开发一个简单的redis 模块 来限制，比如 用 lyh.get 限制客户端请求太大的字符串 key lyh.set限制 写入太大的数据
• 客户端qps限制：1是后端定时扫描 hot key 找到异常用户 拉黑 2、自定义模块 创建全局hash map记录用户操作频率 进行限制

其他安全措施

毕竟redis 不是设计为了面向非可信用户的mq服务器。 一些防患措施还是是要做一下。

• 配置 maxmemory-clients 并经常监控
• tls和明文tcp 都使用，优先使用tls,在负载过大情况下，临时切换到明文，并紧急扩容集群。
• 为了避免可能的安全隐患，客户端应该预留一组redis服务器地址： 这组服务器 应该由可以过滤转发tcp指令的程序反代redis 在redis出现未知漏洞的情况下使用
• 关键性指令 重命名 或者禁用掉
• redis 使用普通无ssh权限的用户运行
• iptable，限制单ip连接频率和连接数
• 如果内容很重要，记得定时备份 redis的持久化文件
• 核心数据如果使用redis储存，需要和客户端可以访问的redis 做隔离。

优点

1、高性能
2、高可用性
3、高扩展性
4、没有中间件，只有后台整理和维护件，后端工作量很少
5、低服务器成本，cpu、内存、带宽占用都不会太高

最后说一下缺点

• 在嵌入式设备上 因为没有支持redis集群的客户端（甚至部分环境也没有可用的redis客户端），需要自己实现 ，不过因为我们允许这部分客户端能使用指令很少，所以并不复杂。知道redis 就是 命令+换行 来通讯的就够了
• 需要redis自定义模块 进行高阶防护 不过真的不难，尤其是对熟悉C的嵌入式开发人员，当然其他语言也可以
• 云厂商的redis通常不可以导入自定义模块
• redis目前不支持websocket 官方说后续有可能会支持，在确实需要的情况下可以起一个后端程序转发ws到redis
  golang实现的：https://dev.leiyanhui.com/golang/ws-redis/
  官方进展关注: https://github.com/orgs/redis/projects/4/views/1?filterQuery=http&pane=issue&itemId=24785018
• redis目前不支持auth验证次数限制 8年了还没添加的功能 ，8年后的今天我们依旧需要自己在防火墙限制过滤auth指令
  官方进展关注：https://github.com/redis/redis/pull/1241
• redis目前不能避免单一用户多次连接，需要自己后端扫描，官方没有支持计划,暂时可以用iptable略微临时限制 和后台扫描。我已经自己修改完成redis的自动离线重复登陆的用户 目前运行良好。
• redis目前不能尽快自动踢出 没有进行 auth 的空连接 ，暂时只能自己在iptable限制，不过根据我的使用 多数mq服务器 都不支持。
• redis acl的持久化在rdb/aof文件中，目前是可以手动保持到acl文本文件的，不过这里有一个pull 是 等待批准 状态 https://github.com/redis/redis/pull/10369
• redis auth 没有防止穷举的措施 目前暂时没有解决办法，客户端可以在一秒内发起几万次auth请求，拖垮redis，只能等待官方更新 https://github.com/redis/redis/pull/11554

权衡后

因为现有app和小程序端，依赖http/ws协议，不能直接连接redis 所以app端是无法直接引入，通过服务器端口搭建ws转发到redis又再次引入了中间件
auth 指令没有使用限制，以及 auth之前不能通过自定义模块的方式来替代auth,所以导致此问题 除了修改redis源码和等待官方更新之外，可以通过防火墙适当防止一下，然后暂时无解（云厂商的公网redis一般直接限制了最大连接数）