09 | 交友系统设计：哪种地理空间邻近算法更快？
该思维导图由 AI 生成，仅供参考
需求分析
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文详细介绍了一款基于地理位置服务的交友应用“Liao”系统设计，重点讨论了邻近位置算法的选择。首先分析了Liao面临的技术挑战和用户规模，然后详细设计了系统架构和关键微服务。文章提出了动态网格和GeoHash算法作为更常用的邻近算法，并对它们的优缺点进行了分析。最终，Liao选择了使用Hash表存储的GeoHash算法，以满足邻近交友的应用场景。文章强调了算法在软件编程中的重要性，指出架构和算法是一个复杂系统的一体两面，对于架构师来说，掌握关键算法同样至关重要。文章提出了一个思考题，即忽略了常规的性能指标，鼓励读者分享对设计文档的评审意见。整体而言，本文通过对交友系统设计的技术挑战和解决方案的详细阐述，为读者提供了对地理空间邻近算法选择的思路和方法，对于开发类似应用的技术人员具有一定的参考价值。
《李智慧 · 高并发架构实战课》，新⼈⾸单¥59
全部留言(12)
- 最新
- 精选
易企秀-郭彦超事实上用户是会自主行走的 ，当用户地理空间发生移动时，如何更新数据呢作者回复: 用户打开App的时候，更新数据：删除旧的位置hash key的用户，添加到新的位置hash key。所以应用还需要记录键值对：用户->位置。
2022-03-079
👽目标用户10亿 预估日活10%=1亿，月活20%=2亿 TPS：每个用户，没天滑动10个目标用户。1亿*10=10亿。 互相发送消息20条。1亿*2*20=40亿。 TPS=50亿/86400 假设同时在线用户，预估5%=500万 带宽：由于文字占用的带宽极小，个人认为，可忽略不计。主要占用带宽的资源为图片资源。 平均每个用户，发送5张图片表情包。其中2张新增，3张服务器保存。一张表情包100kb。 假设同时护发图片的用户10%=50万。带宽=50万*2*100kb。 如果应用允许互相发送视频，音频，文件，则另外计算。 存储：基于上面的预估结果。图片等静态资源需要在服务器保存7天，日活1亿*每个用户每天2张新增图片。7天图片存储=1亿*2*100k*7 并且同时，允许每个用户收藏100个静态资源（预估平均使用率10%）。但是需要考虑资源的重复性，假设70%为重复资源。收藏资源存储=10亿*10%*30%*100k。 由于是社交平台，平均每个用户除了头像外，存在1-9张高质量照片。该照片素质为应用卖点，所以不做过度压缩。预计一张图片1mb。平均使用3张高质量图片资源。用月活 20亿*3*1mb。补充：这个图片的上传和访问也需要放在带宽的计算上面。 这些估算肯定不严谨，只是单纯列一下估算的思路。作者回复: 赞，思路很清晰
2022-03-076
peter请教老师几个问题啊： Q1：网关可以是最外层吗？ 本文中的架构图，请求直接到网关，网关在最外层，这可以吗？ 微服务开发，现在一般用springcloud,其网关是spring gateway,可以让请求直接到spring gateway吗？（有的说最好不要让spring gateway在最外面，其前面最好加一个nginx）。 Q2：每个微服务用自己独立的DB吗？ 本文中的架构图，有几个微服务共用了一个DB。但有的说“微服务之间相互独立，DB也相互独立，即一个微服务用一个DB”。请问，具体该怎么做？ Q3：算法微服务用redis吗？ 文中的算法微服务需要用redis的geo函数，那么，算法微服务是怎么实现的？ 是采用“java代码 + redis”吗？（即创建一个java微服务，运行在一台机器上，同时在这台机器上部署redis） Q4：网格内距离计算用什么？ 最好缩小到一个网格内的时候，用户数大约500，此时计算距离是用半正矢公式公式吗？ Q5：纬度为负值，怎么纬度的第一个bit为1？ “经、纬度 <43.60411, -5.59041> 的二进制编码过程”，纬度是-5.5，是一个负值，第一次计算，平均值是0，-5.5小于0啊，怎么算出来是1？作者回复: 1 网关前应该有负载均衡，文中简化省略了。spring+nginx是正确用法 2 微服务可以共用db，db独立的主要考虑是为了降低负载压力。 3 java和redis不会在一个机器上，微服务架构下尤其不会。PS：文中算法用redis，但是并没有用redis的geo函数。 4 是的 5 -5.5是经度longitude，是0。文中经、纬度的叫法是人们习惯叫法；二元组<43.60411, -5.59041> 写法，纬度在前，经度在后，是经纬度的习惯写法。
2022-03-072
赵常权geohash 维度第7 9 10 行 43.60411大于纬度平均值 为什么是0呢作者回复: 这里纬度应该是42.60411，感谢提醒，我修正一下
2022-03-1031- Geek_474df85位geohash，应该是4.9km*4.9km
作者回复: 确实，正负误差应该✖️2，感谢提醒，我修改一下
2022-04-18 
zhaobk老师好，请问，postgresql 有个gis插件，是否可以考虑用于计算查找临近的好友？作者回复: 不了解这个插件，感谢提示。不过数据库上的操作负载压力必然是满足不了我们这个场景需求的，太笨重了。
2022-03-113
逐风geoHash有办法对临近的用户进行距离排序吗作者回复: Z阶曲线本身就是一个排序
2022-03-092
qc10亿用户这个规模下，我们应该采用什么存储方案记录用户之间的好友关系呢？作者回复: 暴力一点的话，在用户表里，好友用一个字段就可以记录了，关注好友有上限，一般2000个，好友id用整型，字段最大长度8k。
2022-03-093
静心GeoHash的算法确实很巧妙，但如果按这样存储，如何按不同的距离过滤用户呢？要生成不同网格大小的GeoHash码吗？感觉应该有更好的方法。作者回复: 用GeoHash码的长度控制网格大小，网格大小是固定的。
2022-03-08
zhengyu.nie之前做附近地址推荐用的是google s2算法，比geohash好一些，geohash有局限性2022-10-26归属地：浙江1
