still_five_Days的博客

我们直接在并发编程阶段学习过synchronized lock这些都是单机锁。什么是锁呢?就是我们有一些互斥资源，不能并行执行，需要一个东西来保证是串行执行的单机锁的弊端如图，有3个独立的订单服务，4个用户并发从客端访问，用户12访问订单服务1，由于单机锁，所以可以有一个用户能够进行支付操作，用户3 用户4分别进入订单服务2 订单服务3 也能够进行支付操作，因此我们想让4个用户在一个时间内只有一个用户能够进行支付操作，单机锁就无法做到所以就引入了分布式锁。

采用RDB或者不持久化，就会有数据丢失，因为是手动或者配置以快照的形式来进行备份。解决: 启用AOF，以命令追加的形式进行备份，但是默认也会有1s丢失，这是在性能与数据安全性中寻求的一个最适合的方案，如果为了保证数据一致性，可以将配置更改为always，但是性能很慢，一般不用。

redis是内存型数据库，因此每次机器关机都会清理内存，因此，要想保证redis的可用性，就需要持久化技术，redis持久化分为RDB快照和AOF追加两种形式;但是为了高可用，流量的分发以及为了应对redis挂了之后的可用性，引入了主从，主从之间就又设计到了数据的全量同步和增量同步;随后，为了更进一步的将主从切换智能化，提出了sentinel哨兵模式，可用监控主的状态，采用一定的策略，保证主挂了以后从可以升级为主;

用lrulock与redisObject.lru进行比较，因为Lrulock只获取了当前秒单位时间的后24位，所以肯定有个轮询所以，我们会用lrulock跟redisObject.lru进行比较，如果lrulock>redisObject.lru，那么我们用lrulock-redisObject.lru，否则lrulock+(24bit的最大值-redisObject.lru),得到的lru越小，那么返回的数据越大，相差越大的越优先会被淘汰!

1.当没有子进程在进行RDB或者AOF时，已使用的数量大于等于hash表的size时就发生扩容;2.当有子进程在进行EDB或者AOF时，已使用的数量需要大于hash表size的5倍时才进行扩容。

redis中String的底层没有用c的char来实现，而是使用SDS数据结构( char buf[])。:浪费空间1.c字符串不记录自身的长度，所以获取一个字符串长度的复杂度是O(N),但是SDS记录分配的长度alloc,已使用长度len，获取长度的复杂度为O(1)。比如，为char，必须一个个遍历，直到遍历到\0，字符串越长，那么速度越慢2.可以减少字符串修改带来的内存重分配次数字符串更改必须要先申明内存，否则会导致内存溢出。

redis起初主要就是为了解决性能问题的，那么redis为什么快?基于内存操作的，所以操作不需要跟磁盘进行交互，单次的执行会很快命令执行是单线程 因为基于内存操作 单次执行时间反而比线程切换的时间快Redis本身就是一个k-v结构，类似hashmap 所以查询性能是接近O(1)的底层的数据结构 比如说跳表、sds(空间换时间)网络模型 IO多路复用以下简单介绍redis的一些常见数据类型以及可以使用到的应用场景。