redisshake

Redis使用规范 在公司项目中，redis属于高频使用，在使用中，我们遇到了各种各样的redis问题，于是针对自身情况梳理了一个redis使用规范。 一、键名设计 1、key名设计 禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符) 建议以业务名为前缀，以冒号分割来构造一定规则的key名(比如业务名:表名:id) 比如:teach:leeson_id:21 控制key的长度 key太长量一大起来就会非常占用内存 2、value设计 拒绝大key操作 禁用超过10K的string大key(虽然redis支持512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB。 错误示范：直接将laravel的整个模型或者对象当成value存储 设计key时使用合适的数据类型(在资源利用和性能之间作平衡) 错误示范：一个普通字符串弄成hash类型进行存储 一定要控制key的生命周期 错误示范：key设置为永不过期 控制value长度 比如string类型，如果value为'8个字节的长整型'则内部使用int类型，如果value为'小于等于39个字节的字符串'则内部使用embstr类型，如果value为'大于39个字节的字符串'则内部使用raw类型。这样能很好的利用redis的性能。 数据按需存储 不需要的数据千万不要存储在redis

作者：陈金元（今远），阿里云管控技术专家 一、整体说明 上图是云数据库Redis&MongoDB的安全体系图，横向是实例控制链路，纵向是实例数据链路，对于控制链路，事前为了避免恶意操作或者误操作的发生，云数据库Redis&MongoDB提供了多个维度的授权机制，并通过风控系统进行释放保护，在极端场景下安全风险事件发生时，通过云监控可以第一时间发现问题，通过控制台以及审计日志可以快速的定位问题，当风险发生后，通过系统提供的各项恢复能力可以快速恢复业务，针对实例删除，可以使用回收站，针对数据删除（比如执行flushall），可以通过控制台数据恢复，shake工具，PITR，DBS等方式快速恢复数据。 Redis&Mongo实例数据链路的安全能力，分为 接入层，网络层，代理层（proxy），引擎层，存储层 共5个维度。 接入层，也是访问实例的入口，提供云盾，堡垒机，DMS等产品，云盾和堡垒机是阿里云团队提供的安全解决方案，DMS作为数据库生态工具，提供了完善、成熟的数据安全访问解决方案，从访问和变更两个方面进行安全管控。 网络层，通过VPC进行网络隔离，通过白名单和安全组拦截未经授权的访问，通过SSL加密保证数据传输的安全性。 代理层，通过proxy审计日志，在安全风险发生时可以快速定位到clientip，及时进行阻断。 引擎层，通过Redis账号ACL，高危命令拦截，MongoDB