高并发读与高并发写的项目总结和mongodb使用中遇到的坑

最新推荐文章于 2024-08-16 08:52:21 发布

xkey

最新推荐文章于 2024-08-16 08:52:21 发布

阅读量2.5w

点赞数 14

分类专栏：杂谈文章标签： mongodb thrift golang

本文链接：https://blog.csdn.net/Acceptedxukai/article/details/54016342

版权

本文分享了一个需要同时处理高并发读写需求的项目经验，由于数据变化频繁，无法依赖缓存，选择了MongoDB作为数据库，并详细探讨了通信协议选择、数据库选型、架构部署以及在使用go-mgo/mgo库时遇到的问题和解决策略。

摘要由CSDN通过智能技术生成

最近开发了一个既要高并发写又要高并发读的项目，写的QPS比读还要高，这个需求几乎是变态的，任何缓存的工具都没法使用，数据在一秒内可能变化的几十遍，只能每次请求都实时从数据库读取。下面分如下几点介绍我们是如何技术选型的。

一、选择通信协议

之前写的项目并发量很小，http+keepalive完全可以搞定了，此项目http完全架不住，因为使用http协议传递数据，那么数据最友好的格式就是json，但是亲测过json的序列化和反序列化的耗时不可以忍受，并且随着数据量的增大耗时也将成倍增长，项目的实际应用场景在写操作时每条数据最大在10KB，因此http+json的组合被kill掉。

只能选择常见的RPC方式，thrift、protobuf，protobuf需要自己实现tcp的通信方式，我们项目使用的是golang开发，这两种方式之前都没有在生产环境使用过，thrift仅仅自己玩过，因此就直接选择了thrift，编码的量级也相比protobuf降低好多，不过在代码写差不多的时候发现golang有基于protobuf开源的gRpc包。。。

通信协议选择了thrift，基本确定了C+S的架构模式，Client负责业务端的访问请求（还是走的http，貌似业务那帮人只会写业务逻辑，完全不懂架构的东西，如果懂Client都可以干掉，自己连Server就搞定了），Server负责Client通过thrift协议发来的请求，包括查询DB和计算。