伍六七的博客

Redis Bloom filter 大部分都知道，毕竟属于面试八股文中很重要的一个知识点。它可以用来解决缓存穿透的问题，可以判断 Redis key 是否在 DB 中，从而避免请求 DB 中不存在的数据，造成 DB 压力。它可以使用很小的空间，存储大规模的数据。判断存在不一定存在，但是判断不存在，一定不存在！但是 Redis HyperLogLog，很多人都不知道，但是在计算大规模数据的唯一数据量级的场景下，这是一个既高效又节省空间的方法。

回答出来以上三点，表明你对 Redis 的 String 类型的源码是有研究的，而不是每天只顾 CRUD，只顾写业务。另外，也能表明你的技术深度，面试官一定会对你另眼相看哟！加油！

Cache Aside是一种常见的缓存模式，也是最简单的一种缓存模式。在Cache Aside模式中，应用程序首先从缓存中读取数据，如果缓存中不存在，则从数据库中读取数据，并将数据写入缓存中。在更新数据时，应用程序首先更新数据库中的数据，然后删除缓存中的数据。当下一次请求到来时，应用程序会从数据库中读取最新的数据，并将其写入缓存中。Cache Aside模式的优点是简单易用，缓存和数据库之间的数据一致性较好。

com.netflix.hystrix.HystrixCommand 是 Netflix Hystrix 框架中的核心类，用于实现服务的容错和熔断功能。它通过封装远程服务调用，提供容错处理、熔断机制和监控统计等功能，适用于微服务架构和高并发场景。通过使用 HystrixCommand，可以提高系统的可用性、稳定性和性能。

com.netflix.hystrix.HystrixCommand 是 Netflix Hystrix 框架中的核心类，用于实现服务的容错和熔断功能。它通过封装远程服务调用，提供容错处理、熔断机制和监控统计等功能，适用于微服务架构和高并发场景。通过使用 HystrixCommand，可以提高系统的可用性、稳定性和性能。

在大数据场景下，布隆过滤器是一种常用的数据结构，用于快速判断元素是否存在。而 Redis 则是一种流行的缓存和数据存储系统，广泛应用于互联网领域。然而，当布隆过滤器的 key 过大时，会引发 Redis 的崩溃，给系统带来严重的影响。做了刚转行互联网不久的新人，来公司不久，做了一个计算弹窗 CTR 的功能，需要通过设备 id 去重，以计算弹窗的 UV CTR。我这个时候想到了布隆过滤器，在 Redis 存储布隆过滤器，布隆过滤器中存储弹过窗的设备 id。

本文介绍了如何使用 Reactor 和 WebFlux 集成 Redis 来处理缓存操作。通过使用 ReactiveRedisOperations 和 Spring 框架的缓存注解，我们可以方便地实现响应式的缓存逻辑。这种方式可以提升系统的性能和扩展性，特别适用于高并发和大数据量的场景。希望本文对您在使用 Reactor 和 WebFlux 集成 Redis 方面有所帮助。

个人中心系统的特征就是组装各个业务的接口，输出个人中心业务需要的数据，整个系统调用了几十个第三方业务线的接口，如果编排不合理，可能会导致响应时间急剧上涨，尤其是弹窗业务，新的弹窗会不断接入，整个接口可能会不可用。弹窗类业务与一般service不通，它需要调用很多的业务的数据出不同的弹窗，但是每次都只能给用户展示确定的一个。但是如果改成异步的话，又无法控制弹窗之间的优先级，优先级对于公司整体业务来说是必要的，把重要的业务放在高优的位置上，做到资源最大利用，才能实现利润的最大化，从而做到基业长青。

现在很多 ToC 客户端，比如：滴滴、美团、携程等等，都有很多的弹窗，那后端怎么设计更合理、更方便、成本更低呢？我这里说的弹窗是说一级页面的弹窗，比如客户端的首页、个人中心页面、订单页面等。这种一级页面一般都有专门的部门负责，其他业务方需要接入弹窗，需要通过这个部门来接入。

一个对外接口，必须考虑各种异常情况，太多人访问承受不住怎么办？限流、熔断，减少影响范围；下游服务导致访问时间太长怎么办？设置超时；偶发异常导致失败怎么办？重试

reactor 如何并发执行多个任务。然后按照固定顺序返回第一个正常数据呢？

Reactor publishOn 和 subscribeOn 有什么区别？

发生错误了，怎么办？继续呗~

本文介绍 Project Reactor 中的 map 和 flatMap 操作符之间的差异。它们在Mono和Flux类中定义，用于在处理流时转换项。

redis 缓存的三种模式。Cache-Aside、Read/Write-Through、Write-back

读了上一篇文章（【翻译】怎么自定义feign的重试机制）的同学多少了解一些了。这篇文章，我们从头到尾编写一个feign configuration。1 编写FeignConfiguration编写FeignConfiguration，实现RequestInterceptor接口:@Componentpublic class MyFeignConfiguration implements RequestInterceptor { public static final String TOKE

在微服务框架中，通过rest api的方式调用其他服务是很正常的事情。在spring生态系统中，一个流行的REST客户端是Feign，这是因为它的声名式风格和添加不同配置的DRY方式。这篇博客中，我会讨论关于feign客户端的重试机制。本能的，我们会这样实现，在try catch和while循环中编写api调用语句，并为另一个api调用编写代码，直到满足条件。这也许能符合我们的目的，但是这会使得我们的代码丑陋且无法实现。理想情况下，所有东西完美运行，且我们不需要重试任何HTTP请求。因此，在feign中

有的公司，可能有业务监管要求或者成本考虑等因素，使用多个云服务商的服务。那么多云服务间的通信就是个问题，下面提出一些浅显的方案，仅供参考。方案一：IP白名单一句话：改动小，维护难开通 IP 白名单，特定IP来源的请求可以直接调用gateway服务；缺点：如果因为服务升级，需要扩容，这个时候对外IP会增加，需要手动添加，如果扩容是自动操作，那么这个事情下，会造成很多请求不通，这个问题还是很大的。方案二：openFeign一句话：持续改动，有延迟通过Spring cloud 提供的 openFei