ireader

像微信 "附近的人" ，美团 "附近的餐厅" ，支付宝共享单车 "附近的车" 是怎么设计实现的呢？ 一、使用数据库实现查找附近的人 我们都知道，地球上的任何一个位置都可以使用二维的 经纬度 来表示，经度范围 [-180, 180] ，纬度范围 [-90, 90] ，纬度正负以赤道为界，北正南负，经度正负以本初子午线 (英国格林尼治天文台) 为界，东正西负。比如说，北京人民英雄纪念碑的经纬度坐标就是 (39.904610, 116.397724) ，都是正数，因为中国位于东北半球。 所以，当我们使用数据库存储了所有人的 经纬度 信息之后，我们就可以基于当前的坐标节点，来划分出一个矩形的范围，来得知附近的人，如下图： 所以，我们很容易写出下列的伪 SQL 语句： SELECT id FROM positions WHERE x0 - r < x < x0 + r AND y0 - r < y < y0 + r 如果我们还想进一步地知道与每个坐标元素的距离并排序的话，就需要一定的计算。 当两个坐标元素的距离不是很远的时候，我们就可以简单利用 勾股定理 就能够得出他们之间的 距离 。不过需要注意的是，地球不是一个标准的球体， 经纬度的密度 是 不一样 的，所以我们使用勾股定理计算平方之后再求和时，需要按照一定的系数 加权 再进行求和。当然，如果不准求精确的话，加权也不必了。 参考下方

一、前言 我们先来看看传统的三层架构，如下图所示： 从上图中我们可以看到：在传统的三层架构中，层与层之间是相互依赖的，UI层依赖于BLL层，BLL层依赖于DAL层。分层的目的是为了实现“高内聚、低耦合”。传统的三层架构只有高内聚没有低耦合，层与层之间是一种强依赖的关系，这也是传统三层架构的一种缺点。这种自上而下的依赖关系会导致级联修改，如果低层发生变化，可能上面所有的层都需要去修改，而且这种传统的三层架构也很难实现团队的协同开发，因为上层功能取决于下层功能的实现，下面功能如果没有开发完成，则上层功能也无法进行。 传统的三层架构没有遵循依赖倒置原则（DIP）来设计，所以就会出现上面的问题。 二、依赖倒置 依赖倒置(DIP)：Dependence Inversion Principle的缩写，主要有两层含义： 高层次的模块不应该依赖低层次的模块，两者都应该依赖其抽象。 抽象不应该依赖于具体，具体应该依赖于抽象。 我们先来解释第一句话：高层模块不应该直接依赖低层模块的具体实现，而是应该依赖于低层模块的抽象，也就是说，模块之间的依赖是通过抽象发生的，实现类之间不应该发生直接的依赖关系，他们的依赖关系应该通过接口或者抽象类产生。 在来解释第二句话：接口或者抽象类不应该依赖于实现类。举个例子，假如我们要写BLL层的代码，直接就去实现了功能，等到开发完成以后发现没有使用依赖倒置原则

Redis 提供的 Geo 指令只有 6 个，它只是一个普通的 zset 结构。 增加 geoadd 指令携带集合名称以及多个经纬度名称三元组，注意这里可以加入多个三元组 127.0.0.1:6379> geoadd company 116.48105 39.996794 juejin (integer) 1 127.0.0.1:6379> geoadd company 116.514203 39.905409 ireader (integer) 1 127.0.0.1:6379> geoadd company 116.489033 40.007669 meituan (integer) 1 127.0.0.1:6379> geoadd company 116.562108 39.787602 jd 116.334255 40.027400 xiaomi (integer) 2 距离 geodist 指令可以用来计算两个元素之间的距离，携带集合名称、2 个名称和距离单位。 127.0.0.1:6379> geodist company juejin ireader km "10.5501" 127.0.0.1:6379> geodist company juejin meituan km "1.3878" 127.0.0.1:6379> geodist company juejin