Redis也可以使用List数据类型当做队列使用，一个客户端使用rpush生产数据到Redis中，另一个客户端使用lpop取出数据进行消费，非常方便。但要注意的是，使用List当做队列，缺点是没有ack机制和不支持多个消费者。没有ack机制会导致从Redis中取出的数据后，如果客户端处理失败了，取出的这个数据相当于丢失了，无法重新消费。所以使用List用作队列适合于对于丢失数据不敏感的业务场景，但它的优点是，因为都是内存操作，所以非常快和轻量。 而Redis提供的PubSub，可以支持多个消费者进行消费，生产者发布一条消息，多个消费者同时订阅消费。但是它的缺点是，如果任意一个消费者挂了，等恢复过来后，在这期间的生产者的数据就丢失了。PubSub只把数据发给在线的消费者，消费者一旦下线，就会丢弃数据。另一个缺点是，PubSub中的数据不支持数据持久化，当Redis宕机恢复后，其他类型的数据都可以从RDB和AOF中恢复回来，但PubSub不行，它就是简单的基于内存的多播机制。 之后Redis 5.0推出了Stream数据结构，它借鉴了Kafka的设计思想，弥补了List和PubSub的不足。Stream类型数据可以持久化、支持ack机制、支持多个消费者、支持回溯消费，基本上实现了队列中间件大部分功能，比List和PubSub更可靠。 另一个经常使用的是基于Redis实现的布隆过滤器，其底层实现利用的是String数据结构和位运算，可以解决业务层缓存穿透的问题，而且内存占用非常小，操作非常高效。

1，作者讲了什么？ Redis的三种扩展数据类型之一：GEO，一种可以实现LBS服务的数据结构 2，作者是怎么把这事给讲明白的？ 1，提出一个真问题：打车软件是怎么基于位置提供服务的 2，通过GEO原理讲解，说明GEO为什么可以 3，作者为了把这事给讲清楚，讲了那些要点？有哪些亮点？ 1，亮点1：GEO的原理，这个是我之前所不知道的，学完后对GEO有了一些认知 2，亮点2：Redis居然支持自定义数据存储结构，这打开了我的眼界 3，要点1：GEO的底层实现，是sortSet，元素是车辆信息，权重是车辆经纬度转换过来的float值 4，要点2：GEOHash编码，基本原理“二分区间，区间编码”（二分法的应用，将一个值编码成N位的二进制值） 5，要点3：GEO使用GEOHash编码后，将经纬度，按照纬奇经偶位分别填充组合，得到一个车辆的经纬度编码值 6，要点4：GEOHash编码实现的效果是将一个空间分割成为一个个方块，可以实现LBS服务（但编码值相近，不一定位置相近） 4，对于作者所讲，我有哪些发散性思考？ ①：这一篇讲了通过Redis的GEO数据类型可以实现LBS服务，让我体验到了算法的巧妙应用带来的巨大便利（这应是科技让生活更美好的实例）。 ②：不过，我觉得最大的惊喜在于作者介绍了如何自定义一种新的数据类型，虽然我尚未掌握开发新数据类型的能力。 ③：通过作者的讲解，拓宽了我了见识，这让我体验到了购买专栏的价值（如果都是搜索引擎能解决的事，何必买专栏）。 ④：作者细致的讲解开发过程，也让我对Redis的数据结构，RedisObjecti有了进一步认识（面向对象等） 5，在未来的那些场景中，我能够使用它？ redis采用的GEOHash算法，貌似可以协助我们处理分省的一些业务 6，留言区的收获

1、作者讲了什么？ GEO 的数据结构原理，及特点。还有编写 Redis 新数据结构和命令的步骤（此部分我没细看）。 2、作者是怎么把事情说明白的？ 通过利用 LBS(Location-Based Service)  位置信息服务 来说引入 GEO 这个数据结构如何编码地理位置的经纬度信息，写成一个数值，再利用 Sorted Set 进行存储。 3、为了讲明白，作者讲了哪些要点？哪些是亮点？ 举例子说明，Hash、Sorted Set 如何无法满足 LBS 服务； 讲述 Geo Hash 的过程（二分区间，区间编码）： 将一个数值通过二分拆解，形成一个二叉树结构，得到每层的 bool 值，从而通过N位 bit 对一个数值进行存储。N 越大，精度越高； 将经纬度，分别按照 step1 获得两个 N 位bit，在进行交叉组合，得到一个值，就是 Geo Hash 值。 这个 Geo Hash 值是连续的，但位置不一定是连续的。故需要计算多个经纬度所在的方格，在求得邻居节点的较低，已提高 LBS 准确率。 4、对于作者所讲，我有哪些发散性思考？ 车辆的位置信息已经存储在 GEO 集合中了，投入一个 GEO 的值，如何获得它周围的范围值呢？ 5、在未来哪些场景，我可以使用它？ LBS 服务可以考虑实现它，已和公司的一个上司沟通个，大家就这个问题有了共识。nice