qq_53999369的博客

而在m2里有尝试获取锁，在m1调用m2，所以他们是在一个线程里，一个线程两次的来获取锁，这就是锁的重入。刚才解决了我们自定义redis分布式锁的不可重入问题，但是还存在着锁时不可重试的，而且超时释放的隐患也没能得到解决，最后就是主从一致性的问题。我们源码里面的tryLock时可以提供参数的，在给定的参数时间内如果没有获取到锁时可以不停的重新尝试获取锁，成功与否返回true和false。，这个thread1也就是锁的标识，其目的就是将来在释放锁时会判断避免误删，只有锁时自己的才会去删除。

这时候如果锁时不可重入的，那么在a()里获取的锁，在b()时又想获取这把锁，显然是无法获取的，所以这时候就回去等待a()锁的释放，而锁时无法释放的，于是就会出现死锁。虽然这些问题多多少少都存在隐患，但是概率小到可以忽略不计，自己去实现代价太多，但是不实现心里总不踏实，所以我们来找找有没有什么成熟的框架可以让我们直接调用。这是一个风险，但是如果设置的太长，万一出现了故障，在很长的一段时间里都要等待这个锁的释放，这样的锁的阻塞周期就过长。所以这个超时释放问题还是要解决，如果这个时间设置的太短，

单体架构上，乐观锁和悲观锁可以锁住并发情况下的同步代码块，我们多使用synchronized来对方法加锁。但是在配上负载均衡的集群模式下，普通的synchronized是无法锁住从两台服务器同时进入的请求。JVM内部的锁监视器直接作废。所以锁的监视器一定要在JVM的外部，让所有JVM都去找独一无二的锁监视器来获取锁，这样也就只有一个线程获取锁，也就实现了多JVM的线程互斥。分布式锁核心是实现多进程之间的互斥，而满足这一点的方式有很多，常见的有三种：Mysql、Redis。

Redis的key允许有多个单词形成的层级结构，多个单词之间用冒号。这个格式并非固定，也可以根据自己的需求来删除或添加词条。

以日志的形式记录服务器锁处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录，调操作系统命令进程刷盘。RDB保存的是数据，AOF保存的是增删改查指令。，存储有序元素的时候，是把元素都放入到链表中，然后按照有序集合里面元素的分值从小到大，从左到右进行排序。也就是说，只有网络请求模块和数据操作模块是单线程的，而其他的持久化、集群数据同步等是多线程的。Redis的数据结构有一个Zset，是一个有序集合，它的数据结构是压缩列表或者。，而键值对读写的命令仍然是单线程处理的，..

如下图，我们从下图的 第一级索引层 开始查找，那么要找到结点15，只需要找 结点 1-4-7-10-14-14-15，只需要查询七个结点即可。因为长度字节大于39，他的字节大小就不确定，所以RedisObject和字符串的内存是分开分配的。比如说，在原始的链表中如果要查询结点15，那么一共就需要从结点1开始，到结点15，一共查询15个结点才能找到结点15。（跳表必须是排好序的）出来的，而且新插入的一个节点不受其他层节点的影响。压缩列表的节点是不定的，因为他可以根据存储的内容，动态调整其占用空间的大小。...

redis 数据类型String(字符串)Hast(哈希)List(列表)Set(集合)Zset(sort set:有序集合)五种基本数据类型：String字符串、Hash 哈希、List 列表、Set 集合、ZSet（Sort Set：有序集合）底层数据结构一共有 6 种，分别是:简单动态字符串、双向链表、压缩列表、哈 希表、跳表和整数数组。其对应关系如下图所示：全局哈希表：    hash 可以在 O(1)的时间内计算出 hash 值并且找到对应的

NoSQL，Not Only SQL（不仅仅是 SQL）,泛指非关系型的数据库,区别于 关系数据库。随着互联网 web2.0 网站的兴起，传统的关系数据库在处理 web2.0 网站，特别是超大规模和高并发动态网站已经显得力不从心，出现了很多难以克 服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。