内存数据库主流的有哪些,并给出各自特点

内存数据库有现成的redis，高效存取键值对，键设为你的查询条件，值设为你的查询结果转为字符串

查询时先从redis取，没有再查数据库，并且设置redis的过期时间，这种方式需要项目对实时性要求不高，这样你才能用缓存，而且如果你的项目没有明显的热点，即没有某些内容确定会多次被查到，那你缓存就不会命中，添加缓存反而影响你得速度

redis是一种nosql的内存数据库，感兴趣你可以了解一下，优点就是性能强劲

数据查询请求多就把结果缓存下来，你查数据库再快也没有直接把结果从内存读出来快

同样的sql请求只有第一次查数据库，之后通通读内存

或者你干脆借助这种思想，创建一个全局的map对象，然后查询条件作key

结果作value，就省去了了解redis的过程，把整个数据库装内存不太科学，你有多少条数据啊

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。

因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。

以下，我从数据库架构、选型与落地来让大家入门。

数据库会面临什么样的挑战呢？

业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。

为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。

将数据库的写 *** 作和读 *** 作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。

这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读 *** 作的场景。

因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；

优点：

缺点：

在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。

优点：

缺点：

在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。

这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。

但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈（单个服务器的IO有上限）。

所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。

优点：

缺点：

四、分库分表

在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。

所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。

分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。

优点：

缺点：

注：分库还是分表核心关键是有没有IO瓶颈 。

分片方式都有什么呢？

RANGE（范围分片）

将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。

比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。

优点：

缺点：

HASH（哈希分片）

将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。

优点：

缺点：

讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。

那么，我们应该如何选择数据库架构呢？

虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。

混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。

1、对事务支持

分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。

2、多库结果集合并 （group by，order by）

由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等 *** 作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。

3、数据延迟

主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。

4、跨库join

分库分表后表之间的关联 *** 作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。

5、分片扩容

水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。

6、ID生成

分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。

一、应用层依赖类（JDBC）

这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。

此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等 *** 作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。

中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。

优点

缺点

二、中间层代理类（Proxy）

这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。

所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。

在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是>

一、数据场景 1、表结构简介 任何工具类的东西都是为了解决某个场景下的问题，比如Redis缓存系统热点数据，ClickHouse解决海量数据的实时分析，MySQL关系型数据库存储结构化数据。数据的存储则需要设计对应的表结构，清楚的表结构，有助于快速开发业务，和理解系统。表结构的设计通常从下面几个方面考虑：业务场景、设计规范、表结构、字段属性、数据管理。

2、用户场景

例如存储用户基础信息数据，通常都会下面几个相关表结构：用户信息表、单点登录表、状态管理表、支付账户表等。

用户信息表

存储用户三要素相关信息：姓名，手机号，身份z，登录密码，邮箱等。

CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID', `user_name` varchar(20) NOT NULL COMMENT '用户名', `real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名', `pass_word` varchar(32) NOT NULL COMMENT '密码', `phone` varchar(20) NOT NULL COMMENT '手机号', `email` varchar(32) DEFAULT NULL COMMENT '邮箱', `head_url` varchar(100) DEFAULT NULL COMMENT '用户头像URL', `card_id` varchar(32) DEFAULT NULL COMMENT '身份z号', `user_sex` int(1) DEFAULT '1' COMMENT '用户性别:0-女,1-男', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表'; 单点登录表

用意是在多个业务系统中，用户登录一次就可以访问所有相互信任的业务子系统，是聚合业务平台常用的解决方案。

CREATE TABLE `ms_user_sso` ( `user_id` int(11) NOT NULL COMMENT '用户ID', `sso_id` varchar(32) NOT NULL COMMENT '单点信息编号ID', `sso_code` varchar(32) NOT NULL COMMENT '单点登录码,唯一核心标识', `log_ip` varchar(32) DEFAULT NULL COMMENT '登录IP地址', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户单点登录表'; 状态管理表

系统用户在使用时候可能出现多个状态，例如账户冻结、密码锁定等，把状态聚合到一起，可以更加方便的管理和验证。

CREATE TABLE `ms_user_status` ( `user_id` int(11) NOT NULL COMMENT '用户ID', `account_status` int(1) DEFAULT '1' COMMENT '账户状态：0-冻结,1-未冻结', `real_name_status` int(1) DEFAULT '0' COMMENT '实名认证状态：0-未实名,1-已实名', `pay_pass_status` int(1) DEFAULT '0' COMMENT '支付密码是否设置：0-未设置,1-设置', `wallet_pass_status` int(1) DEFAULT '0' COMMENT '钱包密码是否设置：0-未设置,1-设置', `wallet_status` int(1) DEFAULT '1' COMMENT '钱包是否冻结:0-冻结,1-未冻结', `email_status` int(1) DEFAULT '0' COMMENT '邮箱状态:0-未激活,1-激活', `message_status` int(1) DEFAULT '1' COMMENT '短信提醒开启：0-未开启,1-开启', `letter_status` int(1) DEFAULT '1' COMMENT '站内信提醒开启：0-未开启,1-开启', `emailmsg_status` int(1) DEFAULT '0' COMMENT '邮件提醒开启：0-未开启,1-开启', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户状态表'; 支付账户表

用户交易的核心表，存储用户相关的账户资金信息。

CREATE TABLE `ms_user_wallet` ( `wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '钱包ID', `user_id` int(11) NOT NULL COMMENT '用户ID', `wallet_pwd` varchar(32) DEFAULT NULL COMMENT '钱包密码', `total_account` decimal(20,2) DEFAULT '000' COMMENT '账户总额', `usable_money` decimal(20,2) DEFAULT '000' COMMENT '可用余额', `freeze_money` decimal(20,2) DEFAULT '000' COMMENT '冻结金额', `freeze_time` datetime DEFAULT NULL COMMENT '冻结时间', `thaw_time` datetime DEFAULT NULL COMMENT '解冻时间', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户钱包'; 二、设计规范 1、涉及模块

通过上面几个表设计的案例，可以看到表设计关联到数据库的各个方面知识：数据类型，索引，编码，存储引擎等。表设计是一个很大的命题，不过也遵循一个基本规范：三范式。

2、三范式 基础概念

一范式

表的列的具有原子性,不可再分解，即列的信息，不能分解,关系型数据库MySQL、Oracle等自动的满足。

二范式

每个事实的数据记录只会出现一次, 不会冗余, 通常设计一个主键来实现。

三范式

要求一个表中不包含已经存在于其它表的非主键信息，例如部门和员工的信息，员工表包含部门表的主键ID，则可以关联获取相关信息，没必要在员工表保存相关信息。

优缺点对比

范式化设计

范式化结构设计通常更新快，因为冗余数据较少，表结构轻巧，也更好的写入内存中。但是查询起来涉及到关联，代价非常高，非常损耗查询性能。

反范式化设计

所有的数据都在一张表中，避免关联查询，索引的有效性更高，但是数据的冗余性极高。

建议结论

上述的两种设计方式在实际开发中都是不存在的，在实际开发中都是混合使用。比如汇总统计，缓存数据，都会基于反范式化的设计。

三、字段属性

合适的字段类型对于高性能来说非常重要，基本原则如下：简单的类型占用资源更少；在可以正确存储数据的情况下，选最小的数据类型。

1、数据类型选择 整数类型

TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根据数据类型范围合理选择即可。

实数类型

FLOAT、DOUBLE、DECIMAL，建议资金货币相关类型使用高精度DECIMAL存储，或者把数据成倍扩大为整数，采用BIGINT存储，不过处理相对麻烦。

字符类型

CHAR、VARCHAR，长度不确定建议采用VARCHAR存储，不过VARCHAR类型需要额外开销记录字符串长度。CHAR适合存储短字符，或者定长字符串，例如MD5的加密结构。

时间类型

DATETIME、TIMESTAMP，DATETIME保存大范围的值，精度秒。TIMESTAMP以时间戳的格式，范围相对较小，效率也相对较高，所以通常情况建议使用。

MySQL的字段类型有很多种，可以根据数据特性选择合适的，这里只描述常见的几种类型。

2、基础用法 *** 作 数据类型

修改字段类型

ALTER TABLE ms_user_sso MODIFY state CHAR(1) DEFAULT '0' ; ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT '1' COMMENT '状态：0不可用,1可用';

修改名称位置

ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAR(32) AFTER update_time ; 索引使用

索引类型：主键索引，普通索引，唯一索引，组合索引，全文索引。这里演示普通索引的 *** 作。MySQL的核心模块，后续详说。

添加索引

ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) ; CREATE INDEX state_index ON ms_user_wallet(state) ;

查看索引

SHOW INDEX FROM ms_user_wallet;

删除索引

DROP INDEX state_index ON ms_user_wallet ;

修改索引

不具有真正意义上的修改，可以把原有的索引删除之后，再次添加索引。

外键关联

用处：外键关联的作用保证多个数据表的数据一致性和完整性，建表时先有主表，后有从表；删除数据表，需要先删从表，再删主表。复杂场景不建议使用，实际开发中用的也不多。

添加外键

ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id) ;

删除外键

ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key ; 四、表结构管理 1、查看结构 DESC ms_user_status ; SHOW CREATE TABLE ms_user_status ; 2、字段结构 添加字段 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT '删除时间' ; 删除字段 ALTER TABLE ms_user_status DROP COLUMN delete_time ; 3、修改表名 ALTER TABLE ms_user_center RENAME ms_user_info ; 4、存储引擎 存储引擎 SELECT VERSION() ; SHOW ENGINES ;

MySQL 56 支持的存储引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默认使用InnoDB，支持事务管理。该模块MySQL核心，后续详解。

修改引擎

数据量大的场景下，存储引擎修改是一个难度极大的 *** 作，容易会导致表的特性变动，引起各种后续反应，后续会详说。

ALTER TABLE ms_user_sso ENGINE = MyISAM ; 5、修改编码

表字符集默认使用utf8，通用，无乱码风险，汉字3字节，英文1字节，utf8mb4是utf8的超集，有存储4字节例如表情符号时使用。

查看编码 SHOW VARIABLES LIKE 'character%'; 修改编码 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4; 五、数据管理 1、增删改查

添加数据

INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ( '1','SSO7637267','SSO78631273612', '2019-12-24 11:56:57','2019-12-24 11:57:01','127001','1' );

更新数据

UPDATE ms_user_sso SET user_id = '1',sso_id = 'SSO20191224',sso_code = 'SSO20191224', create_time = '2019-11-24 11:56:57',update_time = '2019-11-24 11:57:01', login_ip = '127001',state = '1' WHERE user_id = '1';

查询数据

一般情况下都是禁止使用 select *** 作。

SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERE user_id = '1';

删除数据

DELETE FROM ms_user_sso WHERE user_id = '2' ;

不带where条件，就是删除全部数据。原则上不允许该 *** 作，优化篇会详解。TRUNCATE TABLE也是清空表数据，但是占用的资源相对较少。

2、数据安全 不可逆加密

这类加密算法，多用来做数据验证 *** 作，比如常见的密码验证。

SELECT MD5('cicada')='94454b1241ad2cfbd0c44efda1b6b6ba' ; SELECT SHA('cicada')='0501746a2e4fd34e1d14015fc4d58309585edc7d'; SELECT PASSWORD('smile')='B4FB95D86DCFC3F33A3852714DC742C77504479D' ; 可逆加密

安全性要求高的系统，需要做三级等保，对数据的安全性极高，数据在存储时必须加密入库，取出时候需要解密，这些就需要可逆加密。

SELECT DECODE(ENCODE('123456','key_salt'),'key_salt') ; SELECT AES_DECRYPT(AES_ENCRYPT('cicada','salt123'),'salt123');

上述数据安全的管理，也可以基于应用系统的服务(代码)层进行处理，相对专业的流程是从数据生成源头处理，规避数据传递过程泄露，造成不必要的风险。

随着数据安全法、个人信息保护法的颁布实施，数据安全成为各行业数字化转型的重要一环，通过数据库技术创新助力数据安全成为业内热点。

记者调研采访发现，面对数据安全合规以及新应用新场景下的安全防护要求，传统数据库安全防护理念和技术已经开始转变。在大数据环境下进行顶层设计、标准制订，对各大数据组件进行安全审计、访问控制与风险识别，针对结构化与非结构化数据的安全脱敏、加密安全与隐私防护等，都是当前数据库安全防护新趋势的重要问题。

多因素驱动数据库安全发展

近年来，我国数字经济蓬勃发展。最新发布的《中国互联网发展报告2021》显示，2020年我国数字经济规模达到392万亿元，占GDP比重达386%。

“只有保障数据安全，才能筑牢数字经济发展的底线。”达梦数据库高级副总经理付铨表示，数据是数字经济的重要生产资料，是国家核心战略资源和社会重要财富。同时，数据安全问题是关乎数字经济健康有序可持续发展的重大问题。

绿盟科技集团副总裁李晨认为，数据库安全发展主要有两个驱动因素，一是数据库本身的发展促使数据库安全技术发展，二是数据安全相关法律法规和标准规范对数据库安全防护提出新的需求。从技术发展看，大规模的数据存储和处理需求，使得大数据、数据仓库、数据湖以及数据中台得到推广，并应用于分布式数据库、云端数据库等很多场景。从数据安全法律法规看，继等级保护20系列标准提出大数据应用场景的安全防护参考后，数据安全法和个人信息保护法又相继颁布实施，将数据安全要求提高到法律的高度。

在中国信通院数据库应用创新实验室、中国通信标准化协会大数据技术标准推进委员会近日举办的“数据库安全防护新趋势”沙龙上，清华大学计算机系长聘教授李国良表示，标准有助于落实产业政策，促进企业发展。希望更多企业重视相关工作，共同为数据库安全的发展做出贡献。

据中国信通院云大所工程师刘思源介绍，中国信通院深耕数据库领域标准研制、产业研究、政策支撑、评测评估等，依托中国通信标准化协会大数据技术标准推进委员会，已牵头编制近10项数据库领域行业标准和若干团体标准，累计发布数据库白皮书和研究报告近10本，并定期发布评测评估观察，为遴选优质标的提供重要依据。

数据库安全保障网络安全

数据库安全防护是数据安全治理体系的一部分。李晨表示，绿盟科技从数据安全建设顶层设计出发，提出“一个中心，四个领域，五个阶段”的数据安全体系建设思路。以数据安全防护为中心，在组织建设、制度流程、技术工具和人员能力四个领域同时开展建设工作，通过“知、识、控、察、行”五个步骤进行数据安全落地建设。仅就数据库安全技术而言，绿盟科技有数据分类分级、审计与访问控制、脱敏、水印、脱敏后风险评估、数据防护与态势感知和隐私计算相关技术等。

付铨表示，在信息技术快速发展的背景下，需要在网络信息安全关键技术上有更大突破，前提是独立研发，掌握核心技术。在安全问题上，只有数据库没有安全问题，数据才不会泄露或丢失，信息安全才能得到保障。可以说，只有底层的数据库安全了，网络安全才有保障。

据介绍，达梦数据库研发的数据共享集群实现了国产数据库在共享存储集群方面的突破，在性能上与国际同类产品持平。公司产品广泛应用于金融、能源、电信等50多个重要领域。

构筑多维度立体化安全防线

“随着数据价值重要性的凸显以及未来开放性环境下的安全风险日益突出，数据库需要围绕系统整体韧性能力和数据端到端全生命周期安全构建系统整体外部感知能力和机密计算能力，并完善内核审计追溯能力。”华为技术有限公司数据库技术专家朱金伟说。

勒索病毒是当前受到关注的网络安全风险。美创科技产品和解决方案中心总监胡大海表示，为有效抵御勒索病毒威胁，美创科技从防范实践出发，以“零信任”安全理念为基础，推出“勒索防御产品+安全保险+容灾备份”三位一体的勒索病毒风险解决方案，为机构数据安全构筑起多维度、立体化的安全防线。完善的数据容灾备份建设可以在攻击发生前对数据进行备份，在攻击发生后对数据进行恢复，最大程度降低由勒索病毒加密、窃取数据造成的数据丢失乃至业务中断等影响。

据腾讯云计算技术有限公司数据库高级产品经理程昌明介绍，目前腾讯云数据库已经能够从数据沉淀、业务学习、特征总结、风险模型、人为中心以及行为分析等方面，基于大数据分析进行安全治理。

Copyright © 1999-2020, CSDNNET, All Rights Reserved

打开APP

上水若善

关注

2022/08/04、05 day01-2/02：Redis数据类型 原创

2022-08-05 20:40:19

上水若善

码龄2年

关注

文章目录

今日内容

数据存储类型介绍

string

Redis数据存储格式

string类型

string类型数据的基本 *** 作

string类型数据的扩展 *** 作

string类型数据 *** 作的注意事项

string类型应用场景

key的设置约定

hash

list

今日内容

常用的数据类型一共有一下5种：

string

hash

list

set

sorted_set

数据类型实践案例

数据存储类型介绍

业务数据的特殊性

作为缓冲使用

原始业务功能设计

秒杀

京东618活动

天猫双11活动

火车排队购票

运营平台监控到的突发高频访问数据

突发时政要闻，被强势关注围观

高频、复杂的统计数据

在线人数

投票排行榜

附加功能

系统功能优化或升级

单服务器升级集群

Session管理

Token管理

Redis数据类型（5种常用）

string

hash

list

set

sorted_set

string

Redis数据存储格式

Redis自身是一个Map，其中所有的数据都是采用key:value的形式存储

数据类型指的是存储的数据的类型，也就是value部分的类型，key部分永远都是字符串

string类型

[外链转存失败,源站可能有防盗链机制,建议将保存下来直接上传(img-2NBOyzvI-1659702772759)(en-resource://database/4938:1)]

存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型

存储数据的格式：一个存储空间保存一个数据

存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字 *** 作使用，但其本质还是字符串

string类型数据的基本 *** 作

添加/修改数据：set key value

添加/修改多个数据：mset key1 value1 key2 value2…

追加信息到原始信息后部（如果原始信息存在就追加，否则新建）：append key value

获取数据：get key

获取多个数据：mget key1 key2…

获取数据字符个数（字符串长度）：strlen key

删除数据：del key

(integer) 0 代表失败

(integer) 1 代表成功

string类型数据的扩展 *** 作

业务场景

大型企业级应用中，分表 *** 作是基本 *** 作，使用多张表存储同类型数据，但是对应的主键id必须保证统一性，不能重复。Oracle数据库具有sequence设定，可以解决该问题，但是MySQL数据库并不具有类似的机制，那么该如何解决呢？

解决方案：

设置数值数据增加指定范围的值

incr key 如果是数值，则给value做增 *** 作，每次增加1个单位

incrby key increment 增加指定的整数的值（可以为负数）

incrbyfloat key increment 增加指定的小数的值

设置数值数据减少指定范围的值

decr key 如果是数值，则给value做减 *** 作，每次减少1个单位

decrby key increment 减少指定的整数的值（可以为负数）

string作为数值 *** 作

string在redis内部存储默认就是一个字符串，当遇到增减类 *** 作incr，decr时会转成数值型进行计算。

redis所有的 *** 作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响。

注意：按数值进行 *** 作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错。

9223372036854775807（java中long型数据最大值，LongMAX_VALUE）

Tips 1：

redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性

此方案适用于所有数据库，且支持数据库集群

业务场景

“最强女生”启动海选投票，只能通过微信投票，每个微信号每 4 小时只能投1票。

电商商家开启热门商品推荐，热门商品不能一直处于热门期，每种商品热门期维持3天，3天后自动取消热门。

新闻网站会出现热点新闻，热点新闻最大的特征是时效性，如何自动控制热点新闻的时效性。

解决方案

设置数据具有指定的生命周期

setx key seconds value 秒

例如：setex tel 10 1 当10s到达后，tel就失效为空了（没有了）

例如：set tel 2 此命令已经更新，上面的语句已经没有用了

psetex key milliseconds value 毫秒

例如：psetex tel 9999 1

Tips 2：

redis 控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的 *** 作

string类型数据 *** 作的注意事项

数据 *** 作不成功的反馈与数据正常 *** 作之间的差异

表示运行结果是否成功

(integer) 0 -> false 失败

(integer) 1 -> true 成功

表示运行结果值

(integer) 3 -> 3 3个

(integer) 1 -> 1 1个

数据为获取到

(nil) 等同于null 不存在

数据最大存储量

512MB

数值计算最大范围（java中的long的最大值）

±9223372036854775807

string类型应用场景

业务场景

主页高频访问信息显示控制。

例如新浪微博大V主页显示粉丝数与微博数量

解决方案

在Redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可。

eg: user