1.0数据库锁
数据库锁分为排它锁和共享锁
- 共享锁：每个读操作都会加共享锁，但是此时不能写数据。
- 排它锁：只有获取锁的操作可以写数据，此时其他操作不可读不可写
2.0 乐观锁和悲观锁
- 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次拿数据的时候都会上锁，这样别人想那这个数据就会阻塞直到它拿到锁。 传统关系型数据库用到了很多比如行锁，表锁，读写锁，都是做操作前先上锁。
- 乐观锁：拿数据的时候不会上锁，更新的时候会判断数据有没有更新，可以使用版本号和CAS算法实现。乐观锁适用于多读的业务类型，这样可以提高吞吐量。
3.0 分布式锁
分布式锁有这样几个要求：
- 互斥性：在分布式环境下，一个方法在同一时期，只能被一个机器下的一个线程使用。
- 防止死锁。
- 高性能、高可用的获取和释放锁。
- 可重入的特性。
数据库实现
利用数据库的主键唯一性或者使用数据库的排它锁。
redis实现
利用redis的 set if not exit=》 setnx
zooKeeper实现
基于zookeeper临时有序节点可以实现的分布式锁。
大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。
来看下Zookeeper能不能解决前面提到的问题。
-
锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
-
非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
-
不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
-
单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。
4.0 缓存
缓存的定义：把外存上的数据保存在内存上。
缓存策略：
- 基于访问的时间：此类算法按各缓存的被访问时间来组织缓存队列，决定替换对象。如lru
- 基于访问频率：此类算法用缓存项的被访问频率在组织数据。
- 访问时间和频率兼顾。
数据不一致产生的原因：
1.先操作缓存，再写数据库程序之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致。
2.先写数据库，再删缓存，如果写数据库的线程宕机了，没有删除掉数据，也是数据不一致。
解决方法：
- 写库前后都删除一遍缓存，并设置合理的超时时间。
- 将删除失败的key发送到消息队列中重复删除。
5.0 缓存穿透，击穿，雪崩和刷新
- 缓存穿透：缓存穿透是说收到一个请求，但是该请求缓存中不存在，只能去数据库中查询，然后放进缓存。但当好多请求同时访问同一个数据时，业务系统把这些请求全发到了数据库；或者恶意构造一个逻辑上不存在的数据，然后大量发送这个请求，这样每次都会被发送到数据库，最总导致数据库挂掉。
解决方法：
- 布隆过滤器：对所有可能存在的数据哈希到一个足够大的map里面。
- 缓存空对象：如果缓存查询为空，仍然进行缓存，但是过期时间设置比较短。
- 缓存雪崩：如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩。
解决方法：
这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。
- 缓存雪崩：缓存雪崩是指当我们给所有的缓存设置了同样的过期时间，当某一时刻，整个缓存的数据全部过期了，然后瞬间所有的请求都被抛向了数据库，数据库就崩掉了。
解决方法：
解决思路要么是分治，划分更小的缓存区间，按区间过期；要么给每个key的过期时间加一个随机值，避免同时过期，达到错峰刷新缓存的目的