243_Redis_事务_内存回收_分配算法

Redis事务

Redis事务概念

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中

综述redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务没有隔离级别的概念

批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行！

Redis不保证原子性

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行

Redis事务的三个阶段

开始事务 Multi

命令入队  具体命令

执行事务  exec/discard

Redis事务相关命令

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行

组队的过程中可以通过discard来放弃组队

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消

如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚

watch key1 key2 ... #监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断(类似乐观锁) multi # 标记一个事务块的开始（ queued ） exec # 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ） discard # 取消事务，放弃事务块中的所有命令 unwatch # 取消watch对所有key的监控

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> set user bob QUEUED 127.0.0.1:6379> incr user QUEUED 127.0.0.1:6379> set user2 alex QUEUED 127.0.0.1:6379> exec / discard #exec后才真正执行 1) OK 2) (error) ERR value is not an integer or out of range 3) OK 127.0.0.1:6379> get user2 "alex"

Watch 监控

悲观锁：

悲观锁(Pessimistic Lock)， 每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿到这个数据就会block直到它拿到锁。 传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁

乐观锁

乐观锁(Optimistic Lock) 每次去拿数据的时候都认为别人不会修改，所以不会上锁 但是在更新的时候会判断一下再此期间别人有没有去更新这个数据，可以使用版本号等机制， 乐观锁适用于多读的应用类型，这样可以提高吞吐量， 乐观锁策略：提交版本必须大于记录当前版本才能执行更新

Watch 本质是乐观锁, 但是watch可以用来解决并发修改的方法

会在事务开始之前 顶住 一个或多个变量,

当事务执行时(服务收到exec) 就要顺序执行指令，

Redis检查顶住的变量,如果该变量被修改, exec会返回null 告诉客户端执行失败

内存回收机制

Redis不会立即回收内存给操作系统，操作系统是以页为单位回收内存的, 只要这个页上还有一个key 这个页就不能回收, 所以无法立即回收内存页, 但会重新使用这些尚未回收的空闲内存

内存分配算法

Redis使用jemalloc （facebook）库来管理内存, 可以切换tcmalloc（Google）库

通过info memory 查看内存情况

127.0.0.1:6379> info memory # Memory used_memory:725896 used_memory_human:708.88K used_memory_rss:684880 used_memory_rss_human:668.83K used_memory_peak:743832 used_memory_peak_human:726.40K used_memory_peak_perc:97.59% used_memory_overhead:711694 used_memory_startup:660224 used_memory_dataset:14202 used_memory_dataset_perc:21.63% allocator_allocated:1043496 allocator_active:327155712 allocator_resident:339738624 total_system_memory:0 total_system_memory_human:0B used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:313.52 allocator_frag_bytes:326112216 allocator_rss_ratio:1.04 allocator_rss_bytes:12582912 rss_overhead_ratio:0.00 rss_overhead_bytes:-339053744 mem_fragmentation_ratio:1.00 mem_fragmentation_bytes:0 mem_not_counted_for_evict:112 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:49950 mem_aof_buffer:112 mem_allocator:jemalloc-5.2.1-redis active_defrag_running:0 lazyfree_pending_objects:0

指标

含义

used_memory

由 Redis 分配器分配的内存总量，包含了redis进程内部的开销和数据占用的内存，以字节（byte）为单位，即当前redis使用内存大小。

used_memory_human

已更直观的单位展示分配的内存总量。

used_memory_rss

向操作系统申请的内存大小，与 top 、 ps等命令的输出一致，即redis使用的物理内存大小。

used_memory_rss_human

已更直观的单位展示向操作系统申请的内存大小。

used_memory_peak

redis的内存消耗峰值(以字节为单位)，即历史使用记录中redis使用内存峰值。

used_memory_peak_human

以更直观的格式返回redis的内存消耗峰值

used_memory_peak_perc

使用内存达到峰值内存的百分比，used_memory/ used_memory_peak) *100%，即当前redis使用内存/历史使用记录中redis使用内存峰值*100%

used_memory_overhead

Redis为了维护数据集的内部机制所需的内存开销，包括所有客户端输出缓冲区、查询缓冲区、AOF重写缓冲区和主从复制的backlog。

used_memory_startup

Redis服务器启动时消耗的内存

used_memory_dataset

数据实际占用的内存大小，即used_memory-used_memory_overhead

used_memory_dataset_perc

数据占用的内存大小的百分比，100%*(used_memory_dataset/(used_memory-used_memory_startup))

total_system_memory

整个系统内存

total_system_memory_human

以更直观的格式显示整个系统内存

used_memory_lua

Lua脚本存储占用的内存

used_memory_lua_human

以更直观的格式显示Lua脚本存储占用的内存

maxmemory

Redis实例的最大内存配置

maxmemory_human

以更直观的格式显示Redis实例的最大内存配置

maxmemory_policy

当达到maxmemory时的淘汰策略

mem_fragmentation_ratio

碎片率，used_memory_rss/ used_memory。ratio指数>1表明有内存碎片，越大表明越多，<1表明正在使用虚拟内存，虚拟内存其实就是硬盘，性能比内存低得多，这是应该增强机器的内存以提高性能。一般来说，mem_fragmentation_ratio的数值在1 ~ 1.5之间是比较健康的。详解

mem_allocator

内存分配器

active_defrag_running

表示没有活动的defrag任务正在运行，1表示有活动的defrag任务正在运行（defrag:表示内存碎片整理）详解

lazyfree_pending_objects

0表示不存在延迟释放的挂起对象

Redis

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。