说到算法,很多人可能一开始接触到的算法就是二分查找法,这种算法思想容易理解,使用场景也比较多。下面我会分享一些与平时不一样的二分查找法的实现形式:
首先我们先来看一下二分查找法的性能:
在没有对这种算法进行优化的情况下,它的时间复杂度和空间复杂度如下:
more >>积硅步,至千里
Redisson是一个在Redis的基础上实现的Java驻内存数据网络(In-Memory Data Grid),它不仅提供了一系列的分布式的Java常用对象,还提供了许多分布式服务,其中就包含了各种分布式锁的实现。
分布式锁(Lock)和同步锁(Synchronizer),其中就有:
可重入锁(Reentrant Lock)、公平锁(Fair Lock)、联锁(MultiLock)、红锁(RedLock)、读写锁(ReadWriteLock)、信号量(Semaphore)、可过期性信号量(PermitExpirableSemaphore)、闭锁(CountDownLatch)。
以上详细信息均可在官网查询,这里就不多赘述(水)了,下面直接进入正题。
more >>Redis提供了Lua脚本功能,在一个脚本中编写多条Redis命令,可以确保多条命令执行时的原子性。Lua是一种编程语言,它的基本语法可以参考网站:https://www.runoob.com/lua/lua-tutorial.html
本篇文章优化分布式锁的原子性用到的命令不多,重点介绍一下下面这个命令:
1 | # 执行 REdis 命令 |
比如我们执行一条简单的set命令,如下:
more >>要说Redis高并发场景,有一个很典型的场景就是商品秒杀。而在实际开发的过程中,会有各种各样的问题发生,比如:如何保证订单的唯一性、超卖问题、一人一单等问题,以及这些问题在集群模式下也能够正常运行等问题。下面是解决这些问题的方法。由于篇幅问题,会分成几个主题来写。
全局ID生成器,是一种在分布式系统下用来生成全局唯一ID的工具,一般要求满足:唯一性、高性能、高可用、安全性和递增性。而Redis命令可以满足基本都能满足以上的要求,但是安全性需要进一步增强。比如,为了增强ID的安全性,我们可以不使用Redis自增的数值,而是拼接一些其他的信息来增强安全性。
more >>前面给出的哪些解决Redis缓存问题的方法里面,在一个业务系统里面有可能会在多出地方使用到相同或者类似的操作,就需要反复去创建这些方法。既然业务内容操作差不多,那么我们是否可以把这些类给封装成一个适合多种场景的工具类呢?显然,这里就是想要探讨这个问题。可以把一些重复出现的方法封装起来,定义好需要传入哪些参数,等到需要使用的时候,就按要求传入这些方法需要的参数就可以实现这个功能。
下面是对缓存穿透、缓存击穿以及一些基础方法的封装。
首先先创建一个工具类,加上@Component
的注释,并且定义好基础方法:
缓存击穿有相似之处,都是直接绕过Redis缓存去访问数据库,但是场景不一样。缓存击穿应用的场景主要是热点数据或者被频繁访问的数据。缓存击穿指的是某个热点数据过期或者被删除,导致大量请求直接绕过缓存去访问数据库,导致数据库压力瞬间升高,甚至崩溃。解决缓存击穿这个问题,可以使用互斥锁或者分布式的方式,保证同一时间里面,只有一个线程去查询和重建缓存。
下面是模拟两个线程在争夺互斥锁的场景,在同一台服务器下,当线程1拿到互斥锁后,JVM内部的锁监视器就会检测到有线程在运行,其他线程就不能执行了。等到线程1查询数据且重建完缓存后,就会去释放锁。一旦线程1释放锁,线程2就可以拿到互斥锁,接着查询缓存发现已经存在,就会直接返回数据并且释放锁。
more >>首先我们需要知道正常客户端请求到Redis缓存的工作流程:
正常的情况下,如果 客户端请求的数据有做Redis缓存处理的话,就会直接去访问Redis服务器,查询服务器中是否有这个缓存,如果存在,就直接返回响应给客户端;如果没有命中缓存,就会发送SQL命令去数据库,查询到数据后,把数据缓存到Redis服务器并且返回给客户端,等到下次访问这个数据的时候,就可以直接从Redis服务器中取出数据了。但是也存在一些特殊的情况,发送的请求中,访问的数据不存在,就会透过Redis服务器,直接访问到数据库,会大大加重服务器的负担,这就是缓存穿透。
more >>大家都知道,Tomcat服务器并不共享 Session ,当一个项目部署在一个集群时,假设第一次路由分配给到 tomcat01,Session会保存在这台服务器上,但是短时间内当第二次访问时(可以看作是无操作,再次刷新时),被分配到tomcat02上,这台服务器的tomcat就没有Session的,这时显示前端显示未登录,这样显然是不合理的。这就叫Tomcat服务器的Session混淆问题。
Session共享问题主要说的是多台Tomcat并不共享session存储空间,当请求切换到不同tomcat服务器时导致数据丢失的问题。那么久需要思考一个替代的方案了,而且这个替代方案应该满足以下三点:数据共享、内存存储、key:value结构。满足以上三点的,主流的服务器可以选择 Redis 服务器,首先时基于内存存储的,访问速度快;集群数据共享,可以解决session混淆问题;而且是key:value结构存储数据的,存取方便;并且具有各种缓存淘汰机制,不用过于担心性能问题。
more >>