04stone37

文章目录场景1：基数统计方案一：Set方案二：Bitmap方案三：HyperLogLog（推荐）场景2：排序方案一：List方案二：ZSet场景3：LBS场景GEOGeoHash编码编码过程使用注意问题1：突变性问题2：边界性场景4：二值状态统计方案一：Bitmap场景1：基数统计  基数统计是指统计一个集合内不重复的元素，常见应用场景有日活DAU、月活MAU、网页UV等；方案一：Set特点：存储统计元素、精确统计，不适用于海量数据场景，占用内存且会阻塞Redis主线程；说明：如果一定要使用se

持久化机制  Redis是内存型数据库，为了避免应用重启、挂掉或断电等情况导致的数据丢失，Redis提供了持久化机制，即把内存中的数据持久化到磁盘，提升数据的可靠性。Redis提供了两种持久化方案：RDB持久化和AOF持久化。RDB持久化  RDB就是某时刻内存数据的快照，用于机器重启或者从机全量同步。RDB持久化过程为：创建一个单独的子进程；子进程启动后开始将内存数据dump到临时文件；当拷贝完成后用临时文件替换现有的RDB文件（为了保证数据文件的完整性）；AOF持久化  AOF相当

  到底是先操作数据库还是先操作缓存，取决于哪种方案可以避免数据不一致，或者数据不一致的概率更低。下面的分析会基于Cache Aside策略展开，为什么基于Cache Aside策略，请查看博文“缓存更新策略”。方案1：先缓存再数据库  先缓存再数据库的方案，在并发读写情况下，会出现数据不一致的情况，如下图所示。而且，这种不一致情况会伴随着并发量的上升而严重（换句话说，并发量越大，出现的概率越大）。方案2：先数据库再缓存  先数据库再缓存的方案，在删除缓存失败的情况下，会出现数据不一致的情况，如下

Cache Aside缓存策略读请求处理策略缓存命中，直接返回缓存数据；缓存未命中，从数据库加载数据，更新缓存；写请求处理策略（不同点）先更新数据库，然后删除缓存；数据不一致情况情况1： 写请求处理期间，并发的读请求读取到旧数据，写完成后缓存更新到最新数据；（最终一致性）情况2： 读请求处理期间，并发的写请求更新数据，导致缓存最终数据为旧数据；（无法实现最终一致性，实际情况中发生的概率极低，因为需要读请求的处理时间大于写请求处理时间，并且缓存失效，正常情况写请求处理时间大于读