在我看来Redis最为典型的应用就是作为分布式缓存系统，其他的一些应用本质上并不是杀手锏功能，是基于Redis支持的数据类型和分布式架构来实现的，属于小而美的应用。
初识锁
锁的双面性
现在我们写的程序基本上都有一定的并发性，要么单台多进线程、要么多台机器集群化，在仅读的场景下是不需要加锁的，因为数据是一致的，在读写混合或者写场景下如果不加以限制和约束就会造成写混乱数据不一致的情况。
如果业务安全和正确性无法保证，再多的并发也是无意义的。
高并发多半是考验你们公司的基础架构是否强悍，合理正确地使用锁才是个人能力的体现。
凡事基本上都是双面的，锁可以在一定程度上保证数据的一致性，但是锁也意味着维护和使用的复杂性，当然也伴随着性能的损耗，我见过的最大的锁可能就是CPython解释器的全局解释器锁GIL了。没办法好可怕那个锁不像话--《说锁就锁》
锁使用不当不但解决不了数据混乱问题，甚至会带来诸如死锁等更多问题，通俗地说死锁现象：
几年前会出现这样的场景：在异地需要买火车票回老家，但是身份证丢了无法购票，补办身份证又需要本人坐火车回老家户籍管理处，就这样生活太难。
无锁化编程
既然锁这么难以把控，那不得不思考有没有无锁的高并发。
无锁编程也是一个非常有意思的话题，后续可以写一篇聊聊这个话题，本次就只提一下，要打开思路，不要被困在凡是并发必须加锁的思维定势。
假如有一个上述的post请求的URI部分是个覆盖写操作，reqid=abc123789def，服务部署在多台机器，在大前端将流量转发到Nginx之后根据reqid进行哈希
经过Nginx负载均衡相同reqid的请求将被转发到一台机器上，当然你可能会说如果集群的机器动态调整呢？我只能说不要考虑那么多那么充分，工程化去设计即可。
然而转发到一台机器仍然无法保证串行处理，因为单机仍然是多线程的，我们仍然需要将所有的reqid数据放到同一个线程处理，最终保证线程内串行，这个就需要借助于线程池的管理者Disper按照reqid哈希取模来进行多线程的负载均衡。
经过Nginx和线程内负载均衡，最终相同的reqid都将在线程内串行处理，有效避免了锁的使用，当然这种设计可能在reqid不均衡时造成线程饥饿，不过高并发大量请求的情况下还是可以的。
单机锁和分布式锁
锁依据使用范围可简单分为：单机锁和分布式锁。
Linux提供系统级单机锁，这类锁可以实现线程同步和互斥资源的共享，单机锁实现了机器内部线程之间对共享资源的并发控制。
在分布式部署高并发场景下，经常会遇到资源的互斥访问的问题，最有效最普遍的方法是给共享资源或者对共享资源的操作加一把锁。
分布式锁是控制分布式系统之间同步访问共享资源的一种方式，用于在分布式系统中协调他们之间的动作。
结束语：以上就是关于基于Redis的分布式锁和Redlock算法的全部内容，更多内容请关注学步园。