• 我用Redis分布式锁,抢了瓶茅台,然后GG了~~


    在并发编程中,我们通过锁,来避免由于竞争而造成的数据不一致问题。通常,我们以synchronized 、Lock来使用它(单机情况)

    我们来看一个案例:

    高并发下单超卖问题

    1.  @Autowired
    2.      RedisTemplate<String,String> redisTemplate;
    3.  ​
    4.      String maotai = "maotai20210321001";//茅台商品编号
    5.  ​
    6.      @PostConstruct
    7.      public void init(){
    8.          //此处模拟向缓存中存入商品库存操作
    9.          redisTemplate.opsForValue().set(maotai,"100");
    10.     }
    11.  ​
    12.  ​
    13.      @GetMapping("/get/maotai2")
    14.      public String seckillMaotai2() {
    15.          synchronized (this) {
    16.              Integer count = Integer.parseInt(redisTemplate.opsForValue().get(maotai)); // 1
    17.              //如果还有库存
    18.              if (count > 0) {
    19.                  //抢到了茅台,库存减一
    20.                  redisTemplate.opsForValue().set(maotai,String.valueOf(count-1));
    21.                  //后续操作 do something
    22.                  log.info("我抢到茅台了!");
    23.                  return "ok";
    24.             }else {
    25.                  return "no";
    26.             }
    27.         }
    28.     }
    29. 复制代码

    问题分析:

    • 现象:本地锁在多节点下失效(集群/分布式)
    • 原因:本地锁它只能锁住本地JVM进程中的多个线程,对于多个JVM进程的不同线程间是锁不住的
    • 解决:分布式锁(在分布式环境下提供锁服务,并且达到本地锁的效果)

    何为分布式锁

    • 当在分布式架构下,数据只有一份(或有限制),此时需要利用锁的技术控制某一时刻修改数据的进程数。
    • 用一个状态值表示锁,对锁的占用和释放通过状态值来标识。

    分布式锁特点

    • 互斥性:不仅要在同一jvm进程下的不同线程间互斥,更要在不同jvm进程下的不同线程间互斥
    • 锁超时:支持锁的自动释放,防止死锁
    • 正确,高效,高可用:解铃还须系铃人(加锁和解锁必须是同一个线程),加锁和解锁操作一定要高效,提供锁的服务要具备容错性
    • 可重入:如果一个线程拿到了锁之后继续去获取锁还能获取到,我们称锁是可重入的(方法的递归调用)
    • 阻塞/非阻塞:如果获取不到直接返回视为非阻塞的,如果获取不到会等待锁的释放直到获取锁或者等待超时,视为阻塞的
    • 公平/非公平:按照请求的顺序获取锁视为公平的

    基于Redis实现分布式锁

    实现思路:

    锁的实现主要基于redis的SETNX命令:

    SETNX key value

    将 key 的值设为 value ,当且仅当 key 不存在。

    若给定的 key 已经存在,则 SETNX 不做任何动作。

    SETNX 是『SET if Not eXists』(如果不存在,则 SET)的简写。

    返回值: 设置成功,返回 1 设置失败,返回 0

    使用SETNX完成同步锁的流程及事项如下:

    1. 使用SETNX命令获取锁,若返回0(key已存在,锁已存在)则获取失败,反之获取成功
    2. 为了防止获取锁后程序出现异常,导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态,需要为该key设置一个“合理”的过期时间
    3. 释放锁,使用DEL命令将锁数据删除

    实现代码版本1:

    1. @GetMapping("/get/maotai3")
    2. public String seckillMaotai3() {
    3. //获取锁
    4. Boolean islock = redisTemplate.opsForValue().setIfAbsent(lockey, "1");
    5. if (islock) {
    6. //设置锁的过期时间
    7. redisTemplate.expire(lockey,5, TimeUnit.SECONDS);
    8. try {
    9. Integer count = Integer.parseInt(redisTemplate.opsForValue().get(maotai)); // 1
    10. //如果还有库存
    11. if (count > 0) {
    12. //抢到了茅台,库存减一
    13. redisTemplate.opsForValue().set(maotai,String.valueOf(count-1));
    14. //后续操作 do something
    15. log.info("我抢到茅台了!");
    16. return "ok";
    17. }else {
    18. return "no";
    19. }
    20. } catch (Exception e) {
    21. e.printStackTrace();
    22. } finally {
    23. //释放锁
    24. redisTemplate.delete(lockey);
    25. }
    26. }
    27. return "dont get lock";
    28. }
    29. 复制代码

    问题分析:

      1. setnx 和 expire是非原子性操作(解决:2.6以前可用使用lua脚本,2.6以后可用set命令)
    • 2.错误解锁(如何保证解铃还须系铃人:给锁加一个唯一标识)

    错误解锁问题解决:

    1. @GetMapping("/get/maotai4")
    2. public String seckillMaotai4() {
    3. String requestid = UUID.randomUUID().toString() + Thread.currentThread().getId();
    4. /*String locklua ="" +
    5. "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then redis.call('expire',KEYS[1],ARGV[2]) ; return true " +
    6. "else return false " +
    7. "end";
    8. Boolean islock = redisTemplate.execute(new RedisCallback<Boolean>() {
    9. @Override
    10. public Boolean doInRedis(RedisConnection redisConnection) throws DataAccessException {
    11. Boolean eval = redisConnection.eval(
    12. locklua.getBytes(),
    13. ReturnType.BOOLEAN,
    14. 1,
    15. lockey.getBytes(),
    16. requestid.getBytes(),
    17. "5".getBytes()
    18. );
    19. return eval;
    20. }
    21. });*/
    22. //获取锁
    23. Boolean islock = redisTemplate.opsForValue().setIfAbsent(lockey,requestid,5,TimeUnit.SECONDS);
    24. if (islock) {
    25. try {
    26. Integer count = Integer.parseInt(redisTemplate.opsForValue().get(maotai)); // 1
    27. //如果还有库存
    28. if (count > 0) {
    29. //抢到了茅台,库存减一
    30. redisTemplate.opsForValue().set(maotai,String.valueOf(count-1));
    31. //后续操作 do something
    32. log.info("我抢到茅台了!");
    33. return "ok";
    34. }else {
    35. return "no";
    36. }
    37. } catch (Exception e) {
    38. e.printStackTrace();
    39. } finally {
    40. //释放锁
    41. //判断是自己的锁才能去释放 这种操作不是原子性的
    42. /*String id = redisTemplate.opsForValue().get(lockey);
    43. if (id !=null && id.equals(requestid)) {
    44. redisTemplate.delete(lockey);
    45. }*/
    46. String unlocklua = "" +
    47. "if redis.call('get',KEYS[1]) == ARGV[1] then redis.call('del',KEYS[1]) ; return true " +
    48. "else return false " +
    49. "end";
    50. redisTemplate.execute(new RedisCallback<Boolean>() {
    51. @Override
    52. public Boolean doInRedis(RedisConnection redisConnection) throws DataAccessException {
    53. Boolean eval = redisConnection.eval(
    54. unlocklua.getBytes(),
    55. ReturnType.BOOLEAN,
    56. 1,
    57. lockey.getBytes(),
    58. requestid.getBytes()
    59. );
    60. return eval;
    61. }
    62. });
    63. }
    64. }
    65. return "dont get lock";
    66. }
    67. 复制代码

    锁续期/锁续命

    1. /**
    2. * 3,锁续期/锁续命
    3. * 拿到锁之后执行业务,业务的执行时间超过了锁的过期时间
    4. *
    5. * 如何做?
    6. * 给拿到锁的线程创建一个守护线程(看门狗),守护线程定时/延迟 判断拿到锁的线程是否还继续持有锁,如果持有则为其续期
    7. *
    8. */
    9. //模拟一下守护线程为其续期
    10. ScheduledExecutorService executorService;//创建守护线程池
    11. ConcurrentSkipListSet<String> set = new ConcurrentSkipListSet<String>();//队列
    12. @PostConstruct
    13. public void init2(){
    14. executorService = Executors.newScheduledThreadPool(1);
    15. //编写续期的lua
    16. String expirrenew = "" +
    17. "if redis.call('get',KEYS[1]) == ARGV[1] then redis.call('expire',KEYS[1],ARGV[2]) ; return true " +
    18. "else return false " +
    19. "end";
    20. executorService.scheduleAtFixedRate(new Runnable() {
    21. @Override
    22. public void run() {
    23. Iterator<String> iterator = set.iterator();
    24. while (iterator.hasNext()) {
    25. String rquestid = iterator.next();
    26. redisTemplate.execute(new RedisCallback<Boolean>() {
    27. @Override
    28. public Boolean doInRedis(RedisConnection redisConnection) throws DataAccessException {
    29. Boolean eval = false;
    30. try {
    31. eval = redisConnection.eval(
    32. expirrenew.getBytes(),
    33. ReturnType.BOOLEAN,
    34. 1,
    35. lockey.getBytes(),
    36. rquestid.getBytes(),
    37. "5".getBytes()
    38. );
    39. } catch (Exception e) {
    40. log.error("锁续期失败,{}",e.getMessage());
    41. }
    42. return eval;
    43. }
    44. });
    45. }
    46. }
    47. },0,1,TimeUnit.SECONDS);
    48. }
    49. @GetMapping("/get/maotai5")
    50. public String seckillMaotai5() {
    51. String requestid = UUID.randomUUID().toString() + Thread.currentThread().getId();
    52. //获取锁
    53. Boolean islock = redisTemplate.opsForValue().setIfAbsent(lockey,requestid,5,TimeUnit.SECONDS);
    54. if (islock) {
    55. //获取锁成功后让守护线程为其续期
    56. set.add(requestid);
    57. try {
    58. Integer count = Integer.parseInt(redisTemplate.opsForValue().get(maotai)); // 1
    59. //如果还有库存
    60. if (count > 0) {
    61. //抢到了茅台,库存减一
    62. redisTemplate.opsForValue().set(maotai,String.valueOf(count-1));
    63. //后续操作 do something
    64. //seckillMaotai5();
    65. //模拟业务超时
    66. TimeUnit.SECONDS.sleep(10);
    67. log.info("我抢到茅台了!");
    68. return "ok";
    69. }else {
    70. return "no";
    71. }
    72. } catch (Exception e) {
    73. e.printStackTrace();
    74. } finally {
    75. //解除锁续期
    76. set.remove(requestid);
    77. //释放锁
    78. String unlocklua = "" +
    79. "if redis.call('get',KEYS[1]) == ARGV[1] then redis.call('del',KEYS[1]) ; return true " +
    80. "else return false " +
    81. "end";
    82. redisTemplate.execute(new RedisCallback<Boolean>() {
    83. @Override
    84. public Boolean doInRedis(RedisConnection redisConnection) throws DataAccessException {
    85. Boolean eval = redisConnection.eval(
    86. unlocklua.getBytes(),
    87. ReturnType.BOOLEAN,
    88. 1,
    89. lockey.getBytes(),
    90. requestid.getBytes()
    91. );
    92. return eval;
    93. }
    94. });
    95. }
    96. }
    97. return "dont get lock";
    98. }
    99. 复制代码

    锁的可重入/阻塞锁(redisson)

    1. /**
    2. *
    3. * 4,如何支持可重入
    4. * 重入次数/过期时间
    5. * 获取
    6. * 获取
    7. * 获取
    8. *
    9. * 释放
    10. * 释放
    11. * 释放
    12. *
    13. * 基于本地实现
    14. * 还是基于redis但是更换了数据类型,采用hash类型来实现
    15. * key field value
    16. * 锁key 请求id 重入次数
    17. * 用lua实现
    18. *
    19. *
    20. * 5,阻塞/非阻塞的问题:现在的锁是非阻塞的,一旦获取不到锁直接返回了
    21. * 如何做一个阻塞锁呢?
    22. * 获取不到就等待锁的释放,直到获取到锁或者等待超时
    23. * 1:基于客户端轮询的方案
    24. * 2:基于redis的发布/订阅方案
    25. *
    26. *
    27. * 有没有好的实现呢?
    28. * Redisson
    29. *
    30. */
    31. @Value("${spring.redis.host}")
    32. String host;
    33. @Value("${spring.redis.port}")
    34. String port;
    35. @Bean
    36. public RedissonClient redissonClient() {
    37. Config config = new Config();
    38. config.useSingleServer().setAddress("redis://"+host+":"+port);
    39. return Redisson.create(config);
    40. }
    41. @Autowired
    42. RedissonClient redissonClient;
    43. @GetMapping("/get/maotai6")
    44. public String seckillMaotai6() {
    45. //要去获取锁
    46. RLock lock = redissonClient.getLock(lockey);
    47. lock.lock();
    48. try {
    49. Integer count = Integer.parseInt(redisTemplate.opsForValue().get(maotai)); // 1
    50. //如果还有库存
    51. if (count > 0) {
    52. //抢到了茅台,库存减一
    53. redisTemplate.opsForValue().set(maotai,String.valueOf(count-1));
    54. //后续操作 do something
    55. log.info("我抢到茅台了!");
    56. return "ok";
    57. }else {
    58. return "no";
    59. }
    60. } catch (Exception e) {
    61. e.printStackTrace();
    62. } finally {
    63. lock.unlock();;
    64. }
    65. return "";
    66. }
    67. 复制代码

    redisson

    概述

    Redisson内置了一系列的分布式对象分布式集合分布式锁分布式服务等诸多功能特性,是一款基于Redis实现,拥有一系列分布式系统功能特性的工具包,是实现分布式系统架构中缓存中间件的最佳选择。

    下载地址:github.com/redisson/re…

    实现

    1. <dependency>
    2. <groupId>org.redisson</groupId>
    3. <artifactId>redisson</artifactId>
    4. <version>3.8.2</version>
    5. </dependency>
    6. 复制代码
    1. @Bean
    2. public RedissonClient redissonClient() {
    3. Config config = new Config();
    4. config.useSingleServer().setAddress("redis://"+host+":"+port);
    5. return Redisson.create(config);
    6. }
    7. @Autowired
    8. RedissonClient redissonClient;
    9. @GetMapping("/get/maotai6")
    10. public String seckillMaotai6() {
    11. //要去获取锁
    12. RLock lock = redissonClient.getLock(lockey);
    13. lock.lock();
    14. try {
    15. Integer count = Integer.parseInt(redisTemplate.opsForValue().get(maotai)); // 1
    16. //如果还有库存
    17. if (count > 0) {
    18. //抢到了茅台,库存减一
    19. redisTemplate.opsForValue().set(maotai,String.valueOf(count-1));
    20. //后续操作 do something
    21. log.info("我抢到茅台了!");
    22. return "ok";
    23. }else {
    24. return "no";
    25. }
    26. } catch (Exception e) {
    27. e.printStackTrace();
    28. } finally {
    29. lock.unlock();;
    30. }
    31. return "";
    32. }
    33. 复制代码

    源码剖析

    1. 1,加锁的(是否支持重入)
    2. 2,锁续期的
    3. 3,阻塞获取
    4. 4,释放
    5. 复制代码
    1. /**
    2. * 源码如下:
    3. * 1,加锁
    4. * <T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    5. * internalLockLeaseTime = unit.toMillis(leaseTime);
    6. *
    7. * return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
    8. * #如果锁key不存在
    9. * "if (redis.call('exists', KEYS[1]) == 0) then " +
    10. * #设置锁key,field是唯一标识,value是重入次数
    11. * "redis.call('hset', KEYS[1], ARGV[2], 1); " +
    12. * #设置锁key的过期时间 默认30s
    13. * "redis.call('pexpire', KEYS[1], ARGV[1]); " +
    14. * "return nil; " +
    15. * "end; " +
    16. * #如果锁key存在
    17. * "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
    18. * #重入次数+1
    19. * "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
    20. * #重置过期时间
    21. * "redis.call('pexpire', KEYS[1], ARGV[1]); " +
    22. * "return nil; " +
    23. * "end; " +
    24. * "return redis.call('pttl', KEYS[1]);",
    25. * Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
    26. * }
    27. *
    28. * 2,锁续期
    29. * private void scheduleExpirationRenewal(final long threadId) {
    30. * if (expirationRenewalMap.containsKey(getEntryName())) {
    31. * return;
    32. * }
    33. *
    34. * Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
    35. * @Override
    36. * public void run(Timeout timeout) throws Exception {
    37. * //续期函数的真正实现
    38. * RFuture<Boolean> future = renewExpirationAsync(threadId);
    39. *
    40. * future.addListener(new FutureListener<Boolean>() {
    41. * @Override
    42. * public void operationComplete(Future<Boolean> future) throws Exception {
    43. * expirationRenewalMap.remove(getEntryName());
    44. * if (!future.isSuccess()) {
    45. * log.error("Can't update lock " + getName() + " expiration", future.cause());
    46. * return;
    47. * }
    48. *
    49. * if (future.getNow()) {
    50. * // reschedule itself 再次调用自己,最终形成的结果就是每隔10秒续期一次
    51. * scheduleExpirationRenewal(threadId);
    52. * }
    53. * }
    54. * });
    55. * }
    56. * // internalLockLeaseTime=30 * 100030
    57. * }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS); //30/3=10秒后异步执行续期函数
    58. *
    59. * if (expirationRenewalMap.putIfAbsent(getEntryName(), new ExpirationEntry(threadId, task)) != null) {
    60. * task.cancel();
    61. * }
    62. * }
    63. *
    64. * 续期的lua脚本:判断key,field存在则重置过期时间
    65. * protected RFuture<Boolean> renewExpirationAsync(long threadId) {
    66. * return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
    67. * "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
    68. * "redis.call('pexpire', KEYS[1], ARGV[1]); " +
    69. * "return 1; " +
    70. * "end; " +
    71. * "return 0;",
    72. * Collections.<Object>singletonList(getName()),
    73. * internalLockLeaseTime, getLockName(threadId));
    74. * }
    75. *
    76. *
    77. *
    78. * 4,阻塞锁实现
    79. * public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
    80. * long threadId = Thread.currentThread().getId();
    81. * Long ttl = tryAcquire(leaseTime, unit, threadId);
    82. * // lock acquired
    83. * if (ttl == null) {
    84. * return;
    85. * }
    86. * //如果没有获取到锁,则订阅:redisson_lock__channel:{key} 频道
    87. * RFuture<RedissonLockEntry> future = subscribe(threadId);
    88. * commandExecutor.syncSubscription(future);
    89. *
    90. * try {
    91. * while (true) {
    92. * //尝试再获取一次
    93. * ttl = tryAcquire(leaseTime, unit, threadId);
    94. * // lock acquired
    95. * if (ttl == null) {
    96. * break;
    97. * }
    98. *
    99. * // waiting for message 阻塞等待锁订阅频道的消息,一旦锁被释放,就会得到信号通知,继续尝试获取锁
    100. * if (ttl >= 0) {
    101. * getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
    102. * } else {
    103. * getEntry(threadId).getLatch().acquire();
    104. * }
    105. * }
    106. * } finally {
    107. * //获取到锁后取消订阅
    108. * unsubscribe(future, threadId);
    109. * }
    110. * // get(lockAsync(leaseTime, unit));
    111. * }
    112. *
    113. *
    114. * 5,解锁
    115. * protected RFuture<Boolean> unlockInnerAsync(long threadId) {
    116. * return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
    117. * //key已经不存在了,则向redisson_lock__channel:{key}频道发布锁释放消息
    118. * "if (redis.call('exists', KEYS[1]) == 0) then " +
    119. * "redis.call('publish', KEYS[2], ARGV[1]); " +
    120. * "return 1; " +
    121. * "end;" +
    122. * // hash 中的field 不存在时直接返回,
    123. * "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
    124. * "return nil;" +
    125. * "end; " +
    126. * "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
    127. * //重入次数-1后如果还大于0,延长过期时间
    128. * "if (counter > 0) then " +
    129. * "redis.call('pexpire', KEYS[1], ARGV[2]); " +
    130. * "return 0; " +
    131. * "else " +
    132. * //重入次数-1后如果归0,则删除key,并向redisson_lock__channel:{key}频道发布锁释放消息
    133. * "redis.call('del', KEYS[1]); " +
    134. * "redis.call('publish', KEYS[2], ARGV[1]); " +
    135. * "return 1; "+
    136. * "end; " +
    137. * "return nil;",
    138. * Arrays.<Object>asList(getName(), getChannelName()), LockPubSub.unlockMessage, internalLockLeaseTime, getLockName(threadId));
    139. *
    140. * }
    141. */
    142. 复制代码

    布隆过滤器(BloomFilter)

    引言:

    问题1:什么是Redis缓存穿透?缓存穿透如何解决?

    问题2:如何在海量元素中(例如 10 亿无序、不定长、不重复)快速判断一个元素是否存在?

    什么是 BloomFilter

    布隆过滤器(英语:Bloom Filter)是 1970 年由Burton Howard Bloom提出的,是一种空间效率高的概率型数据结构。

    本质上其实就是一个很长的二进制向量和一系列随机映射函数。专门用来检测集合中是否存在特定的元素

    产生的契机

    回想一下,我们平常在检测集合中是否存在某元素时,都会采用比较的方法。考虑以下情况:

    • 如果集合用线性表存储,查找的时间复杂度为O(n)。
    • 如果用平衡BST(如AVL树、红黑树)存储,时间复杂度为O(logn)。
    • 如果用哈希表存储,并用链地址法与平衡BST解决哈希冲突(参考JDK8的HashMap实现方法),时间复杂度也要有O[log(n/m)],m为哈希分桶数。

    总而言之,当集合中元素的数量极多时,不仅查找会变得很慢,而且占用的空间也会大到无法想象。BF就是解决这个矛盾的利器。

    数据结构&设计思想

    BF是由一个长度为m比特的位数组(bit array)k个哈希函数(hash function) 组成的数据结构。位数组均初始化为0,所有哈希函数都可以分别把输入数据尽量均匀地散列。

    基于BitMap:

    如果我们要映射一个值到布隆过滤器中,我们需要使用多个不同的哈希函数生成多个哈希值, 并对每个生成的哈希值指向的 bit 位,设置为1

    例:

    当要插入一个元素时,将其数据分别输入k个哈希函数,产生k个哈希值。以哈希值作为位数组中的下标,将所有k个对应的比特置为1。

    当要查询(即判断是否存在)一个元素时,同样将其数据输入哈希函数,然后检查对应的k个比特。如果有任意一个比特为0,表明该元素一定不在集合中。如果所有比特均为1,表明该集合有(较大的)可能性在集合中。为什么不是一定在集合中呢?因为一个比特被置为1有可能会受到其他元素的影响,这就是所谓“假阳性”(false positive)。相对地,“假阴性”(false negative)在BF中是绝不会出现的。

    • 如果这些点有任何一个 0,则被检索元素一定不在
    • 如果都是 1,则被检索元素很可能在。

    误判率问题分析

    哈希函数有以下两个特点:

    • 如果两个散列值是不相同的(根据同一函数),那么这两个散列值的原始输入也是不相同的。
    • 散列函数的输入和输出不是唯一对应关系的,如果两个散列值相同,两个输入值很可能是相同的。但也可能不同,这种情况称为 “散列碰撞”(或者 “散列冲突”)

    布隆过滤器的误判是指多个输入经过哈希之后在相同的bit位置1了,这样就无法判断究竟是哪个输入产生的,因此误判的根源在于相同的 bit 位被多次映射且置 1。

    不支持删除

    hash碰撞这种情况也造成了布隆过滤器的删除问题,传统的布隆过滤器并不支持删除操作,因为布隆过滤器的每一个 bit 并不是独占的,很有可能多个元素共享了某一位。如果我们直接删除这一位的话,会影响其他的元素。

    如何选择哈希函数个数和布隆过滤器长度

    很显然,过小的布隆过滤器很快所有的 bit 位均为 1,那么查询任何值都会返回“可能存在”,起不到过滤的目的了。布隆过滤器的长度会直接影响误报率,布隆过滤器越长其误报率越小。

    另外,哈希函数的个数也需要权衡,个数越多则布隆过滤器 bit 位置位 1 的速度越快,且布隆过滤器的效率越低;但是如果太少的话,那我们的误报率会变高。

    如何选择适合业务的 k 和 m 值呢,这里直接贴一个公式:

    布隆过滤器实现

    第一种方式:Guava

    1、引入Guava pom配置

    1. <dependency>
    2. <groupId>com.google.guava</groupId>
    3. <artifactId>guava</artifactId>
    4. <version>29.0-jre</version>
    5. </dependency>
    6. 复制代码

    2、代码实现

    1. public class BloomFilterTest {
    2. @Test
    3. public void test1() {
    4. BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, fpp);
    5. // 插入10万样本数据
    6. for (int i = 0; i < size; i++) {
    7. bloomFilter.put(i);
    8. }
    9. // 用另外十万测试数据,测试误判率
    10. int count = 0;
    11. for (int i = capacity; i < size + 100000; i++) {
    12. if (bloomFilter.mightContain(i)) {
    13. count++;
    14. System.out.println(i + "误判了");
    15. }
    16. }
    17. System.out.println("总共的误判数:" + count);
    18. }
    19. }
    20. }
    21. 复制代码

    运行结果:

    10万数据里有947个误判,约等于0.01%,也就是代码里设置的误判率:fpp = 0.01

    代码分析:

    核心BloomFilter.create方法:

    1. @VisibleForTesting
    2. static <T> BloomFilter<T> create(
    3. Funnel<? super T> funnel, long expectedInsertions, double fpp, Strategy strategy) {
    4. 。。。。
    5. }
    6. 复制代码

    这里有四个参数:

    • funnel:数据类型(通常是调用Funnels工具类中的)
    • expectedInsertions:指望插入的值的个数
    • fpp:误判率(默认值为0.03)
    • strategy:哈希算法

    咱们重点讲一下fpp参数

    fpp误判率

    情景一:fpp = 0.01

    • 误判个数:947 占内存大小:9585058位数

    情景二:fpp = 0.03(默认参数)

    • 误判个数:3033 占内存大小:7298440位数

    总结

    • 误判率能够经过fpp参数进行调节
    • fpp越小,须要的内存空间就越大:0.01须要900多万位数,0.03须要700多万位数。
    • fpp越小,集合添加数据时,就须要更多的hash函数运算更多的hash值,去存储到对应的数组下标里。(忘了去看上面的布隆过滤存入数据的过程)

    第二种方式:Redisson

    上面使用Guava实现的布隆过滤器是把数据放在了本地内存中。分布式的场景中就不合适了,没法共享内存

    还能够用Redis来实现布隆过滤器,这里使用Redis封装好的客户端工具Redisson

    pom配置:

    1. <dependency>
    2. <groupId>org.redisson</groupId>
    3. <artifactId>redisson-spring-boot-starter</artifactId>
    4. <version>3.13.4</version>
    5. </dependency>
    6. 复制代码

    java代码:

    1. public class RedissonBloomFilter {
    2. public static void main(String[] args) {
    3. Config config = new Config();
    4. config.useSingleServer().setAddress("redis://127.0.0.1:6379");
    5. config.useSingleServer().setPassword("1234");
    6. //构造Redisson
    7. RedissonClient redisson = Redisson.create(config);
    8. RBloomFilter<String> bloomFilter = redisson.getBloomFilter("phoneList");
    9. //初始化布隆过滤器:预计元素为100000000L,偏差率为3%
    10. bloomFilter.tryInit(100000000L,0.03);
    11. //将号码10086插入到布隆过滤器中
    12. bloomFilter.add("10086");
    13. //判断下面号码是否在布隆过滤器中
    14. //输出false
    15. System.out.println(bloomFilter.contains("123456"));
    16. //输出true
    17. System.out.println(bloomFilter.contains("10086"));
    18. }
    19. }
    20. 复制代码

    Twemproxy

    1.1.1 简介

    cluster是redis官方提供的集群方案,功能确实强大(在线扩容,缩容等等),除了官方的cluster,业界有很多三方的缓存代理中间件,比如: predixy, codis, redis-cerberus,squirrel ,cellar act。Twemproxy是使用最广泛、同时也是redis官方所认可的实现方案。

    1. Twemproxy(又称为nutcracker)由Twitter开源。是一个轻量级的Redis和Memcached代理,主要用来减少对后端缓存服务器的连接数。
    2. 复制代码

    特点:

    memcached时代可以称王称霸,但随着redis自身发展,尤其高版本cluster出现,已逐渐被弱化

    优点:

    简单可靠,具备生产级别应用能力

    减少了redis连接数,降低redis连接成本,cluster的所有节点之间都需要互相建立连接。

    除了redis,Twemproxy可以对Memcached 协议做代理,在缓存界是个通用性的解决方案。

    缺点:

    和cluster相比,性能有一定的损失(twitter测试约20%)

    自身也会成为一个单点,所以,做双活很重要!

    它只是一个代理转发,底层的主从切换等依然靠redis自身的主从和哨兵或cluster。这一点上cluster已经完虐它

    1.1.2 下载与部署

    1. yum install -y autoconf automake libtool
    2. yum remove -y autoconf 
    3. export twemproxy_path=/opt/redis/latest/twemproxy/
    4. mkdir -p $twemproxy_path
    5. cd $twemproxy_path
    6. wget ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
    7. tar -zxvf autoconf-2.69.tar.gz
    8. cd autoconf-2.69 
    9. .configure --prefix=/usr
    10. make && make install
    11. cd $twemproxy_path
    12. wget http://ftp.gnu.org/gnu/automake/automake-1.14.tar.gz
    13. tar -zxvf automake-1.14.tar.gz
    14. cd automake-1.14
    15. .bootstrap.sh
    16. .configure --prefix=/usr
    17. make && make install
    18. cd $twemproxy_path
    19. wget http://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz
    20. tar -zxvf libtool-2.4.2.tar.gz
    21. cd libtool-2.4.2
    22. .configure --prefix=/usr
    23. make && make install
    24. cd $twemproxy_path
    25. wget https://github.com/twitter/twemproxy/archive/v0.4.1.tar.gz
    26. tar -zxvf v0.4.1.tar.gz
    27. cd twemproxy-0.4.1
    28. .configure --prefix=/usr
    29. make && make install
    30. #编译完,启动文件在src目录中。
    31. 复制代码

    1.1.3 配置与启动

    1)先准备好两台redis

    1. #将redis.conf拷贝一份,注意以下配置项
    2. #后台启动
    3. daemonize yes
    4. #bind这一行一定要注释掉!允许外部ip连接,否则将来用redis-cli连接操作命令的时候会报一个错误:
    5. #Error: Connection reset by peer
    6. #bind 127.0.0.1 -::1
    7. #启动两个实例,在8081和8082端口
    8. [root@iZ8vb3a9qxofwannyywl6zZ twemproxy]# pwd
    9. /opt/redis/latest/twemproxy
    10. [root@iZ8vb3a9qxofwannyywl6zZ twemproxy]# ..src/redis-server redis.conf --port 8081
    11. [root@iZ8vb3a9qxofwannyywl6zZ twemproxy]# ..src/redis-server redis.conf --port 8082
    12. #确认服务启动成功
    13. [root@iZ8vb3a9qxofwannyywl6zZ twemproxy]# ps aux | grep redis-server
    14. root 18209 0.1 0.0 162492 2680 ? Ssl 13:35 0:00 ..src/redis-server 127.0.0.1:8081
    15. root 18217 0.0 0.0 162492 2688 ? Ssl 13:35 0:00 ..src/redis-server 127.0.0.1:8082
    16. 复制代码

    2)配置twemproxy

    1. #将yml文件拷贝一份,test.yml,并修改内容为自己的redis地址
    2. [root@iZ8vb3a9qxofwannyywl6zZ conf]# pwd
    3. /opt/redis/latest/twemproxy/twemproxy-0.4.1/conf
    4. [root@iZ8vb3a9qxofwannyywl6zZ conf]# cp nutcracker.yml test.yml
    5. 复制代码
    1. #test.yml文件说明
    2. alpha: #标记,如果多组,就alpha,beta……往上加,参考 nutcracker.yml 样本
    3. listen: 127.0.0.1:22121 # 这组集群暴露的端口,将来连这个
    4. hash: fnv1a_64 #hash散列算法
    5. distribution: modula #分片算法,这里用取模方式,一共三种,后面详细介绍
    6. auto_eject_hosts: true #自动摘除故障节点
    7. redis: true #是不是redis,false则表示memcache
    8. server_retry_timeout: 2000 #每隔2秒判断故障节点是否正常,如果正常则放回一致性hash环
    9. server_failure_limit: 3 #多少次无响应,就从一致性hash环中摘除
    10. #redis实例列表,一定要加别名,否则宕机后更换机器,分片就不一样了
    11. #加了别名后,将用别名做分片节点名,否则用ip加端口权重,一旦ip变更会重新迁移
    12. servers:
    13. - 127.0.0.1:8081:1 redis-1
    14. - 127.0.0.1:8082:1 redis-2
    15. 复制代码
    1. #启动:-d后台启动,-c指定启动文件
    2. [root@iZ8vb3a9qxofwannyywl6zZ conf]# ..src/nutcracker -d -c test.yml
    3. [root@iZ8vb3a9qxofwannyywl6zZ conf]# ps aux | grep nutcracker
    4. root 14601 0.0 0.0 1136 248 pts/0 Ssl+ 09:25 0:00 /usr/sbin/nutcracker -c /opt/nutcracker.yml
    5. 复制代码

    3)连接与验证

    1. #连接非常的简单,用redis-cli和直连redis一样
    2. #首先在twemproxy上设置多个key,均成功
    3. [root@iZ8vb3a9qxofwannyywl6zZ ~]# redis-cli -p 22121
    4. 127.0.0.1:22121> set a a
    5. OK
    6. 127.0.0.1:22121> set b b
    7. OK
    8. 127.0.0.1:22121> set c c
    9. OK
    10. 127.0.0.1:22121> set d d
    11. OK
    12. #先连redis-1 , 取到ac, bd取不到
    13. [root@iZ8vb3a9qxofwannyywl6zZ ~]# redis-cli -p 8081
    14. 127.0.0.1:8081> get a
    15. "a"
    16. 127.0.0.1:8081> get b
    17. (nil)
    18. 127.0.0.1:8081> get c
    19. "c"
    20. 127.0.0.1:8081> get d
    21. (nil)
    22. 127.0.0.1:8081>
    23. #再连redis-2 , 发现ac不存在,bd在这里,验证集群分片成功!
    24. [root@iZ8vb3a9qxofwannyywl6zZ ~]# redis-cli -p 8082
    25. 127.0.0.1:8082> get a
    26. (nil)
    27. 127.0.0.1:8082> get b
    28. "b"
    29. 127.0.0.1:8082> get c
    30. (nil)
    31. 127.0.0.1:8082> get d
    32. "d"
    33. 复制代码

    1.1.4 分片策略

    1)读写原理

    写入时,twemproxy将多个对应的key计算hash值路由到对应的后端redis机器。

    而要在redis集群中查询对应的key/value时,twemproxy同样计算hash值从对应的后端redis收集过来,然后拼接起来返回给用户。

    2)策略

    后台的redis或memcached集群可以通过以下几种算法进行key/value的分配(distribution属性):

    • ketama: 一个实现一致性hash算法的开源库
    • modula: 通过取模的hash算法来选择一个节点
    • random:随机选择一个节点

    经典面试题

    Redis6.x 之后为何引入了多线程?

    答:

    Redis6.0 引入多线程主要是为了提高网络 IO 读写性能(Redis 的瓶颈并不在 CPU,而在内存和网络。)

    虽然,Redis6.0 引入了多线程,但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了, 执行命令仍然是单线程顺序执行。因此,你也不需要担心线程安全问题。

    Redis6.x多线程的实现机制?

    流程简述如下

    • 主线程负责接收建立连接请求,获取 Socket 放入全局等待读处理队列。
    • 主线程处理完读事件之后,通过 RR(Round Robin)将这些连接分配给这些 IO 线程。
    • 主线程阻塞等待 IO 线程读取 Socket 完毕。
    • 主线程通过单线程的方式执行请求命令,请求数据读取并解析完成,但并不执行。
    • 主线程阻塞等待 IO 线程将数据回写 Socket 完毕。
    • 解除绑定,清空等待队列。

    该设计有如下特点:

    1、IO 线程要么同时在读 socket,要么同时在写,不会同时读或写

    2、IO 线程只负责读写 socket 解析命令,不负责命令处理

    Redis6.x默认是否开启了多线程?

    Redis6.0 的多线程默认是禁用的,只使用主线程

    如需开启需要修改 redis 配置文件 redis.conf

    1. io-threads-do-reads yes
    2. 复制代码

    开启多线程后,还需要设置线程数,否则是不生效的。同样需要修改 redis 配置文件 redis.conf :

    1.  io-threads 4 #官网建议4核的机器建议设置为2或3个线程,8核的建议设置为6个线程
    2. 复制代码

    缓存穿透

    • 缓存穿透: key中对应的缓存数据不存在,导致去请求数据库,造成数据库的压力倍增的情况
    • 缓存击穿: redis过期后的一瞬间,有大量用户请求同一个缓存数据,导致这些请求都去请求数据库,造成数据库压力倍增的情,针对一个key而言
    • 缓存雪崩: 缓存服务器宕机或者大量缓存集中某个时间段失效,导致请求全部去到数据库,造成数据库压力倍增的情况,这个是针对多个key而言

    缓存穿透

    概念:缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,造成数据库的压力倍增的情况

    例:发起为id值为 -1 的数据或 id 为特别大不存在的数据

    解决方案:

    (1)接口层增加校验,比如用户鉴权校验,参数做校验 比如:id 做基础校验,id <=0的直接拦截

    (2)对于像ID为负数的非法请求直接过滤掉,采用布隆过滤器(Bloom Filter)

    (3)针对在数据库中找不到记录的,我们仍然将该空数据存入缓存中,当然一般会设置一个较短的过期时间

    缓存雪崩

    概念:缓存服务器宕机或者大量缓存集中某个时间段失效,导致请求全部去到数据库,造成数据库压力倍增的情况,这个是针对多个key而言

    解决:

    (1)实现缓存高可用,通过redis cluster将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题

    (2)批量往Redis存数据的时候,把每个Key的失效时间都加个随机值

    1.  setRedis(Key,value,time + Math.random() * 10000);
    2. 复制代码

    缓存击穿

    概念:redis过期后的一瞬间,有大量用户请求同一个缓存数据,导致这些请求都去请求数据库,造成数据库压力倍增的情,针对一个key而言

    缓存击穿与缓存雪崩的区别是这里针对的是某一热门key缓存,而雪崩针对的是大量缓存的集中失效

    解决方案

     ● 设置热点数据永远不过期。

     ● 使用互斥锁(mutex key)

    好了,今天就先码到这里了,接着去搬砖了,茅台没抢着,倒是学习了不少技术,也是收获颇丰

    希望大家不要吝啬你的小手,给狂野君点个赞,你的认可,是我最大的动力

    以后,会持续为大家送上干货的,欢迎大家关注,以免迷路

    以下是往期Redis的干货,欢迎收藏

    1. 伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我,
    2. 后面会有很多干货。我有一些面试题、架构、设计类资料可以说是程序员面试必备!
    3. 所有资料都整理到网盘了,需要的话欢迎下载!私信我回复【999】即可免费获取

     

    作者:博学谷狂野架构师
    链接:https://juejin.cn/post/7098957369224200200
    来源:稀土掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  • 相关阅读:
    celery笔记三之task和task的调用
    (附源码)ssm本科教学合格评估管理系统 毕业设计 180916
    HTML和CSS基础(一)
    2022年全球市场防火水泥总体规模、主要生产商、主要地区、产品和应用细分研究报告
    gdb命令学习笔记
    238. 银河英雄传说,带权值的并查集
    【项目实战】自主实现 HTTP 项目(五)——返回静态网页
    【数据集制作】用于语义分割,labelme4.5.13版本,实现按照指定颜色生成分割颜色批量转换json文件
    三思近10000㎡天幕屏耀显上海“八万人”体育场
    【zip密码】7-zip分卷压缩方法
  • 原文地址:https://blog.csdn.net/m0_67322837/article/details/124881799