您了解分布式系统进程间通信吗?
进程间通信
关于进程间通信,我前前后后写了不下十篇,后来整理成了一两篇,无非是写:shm共享内存、消息队列、管道等方式。 但是今天我接触到了另外一种以前确实没有想过的进程间通信方法,我把它讲给我的朋友们听,他们都惊呆了。 那就是:TCP实现进程间通信。
本篇不会教你怎么使用TCP,详情请看前言。我们就来聊聊,为什么我们会为这个通信“新”方法而吃惊吧,毕竟也是经历过小风浪的人,是不会因为新奇而有这么大反应。
TCP在进程间通信的优势
首先,就是分布式系统,这点当看到TCP做进程间通信的时候我就想到了。TCP进程间通信可以跨主机,具有伸缩性,把进程分布到不同的服务器上,改改TCP端口就能用了。相反,其他IPC都不能跨机器。
其次,我兄弟天天给我吹他学的服务器到后面可以跨平台,Windows和Linux上交互,我问他他说还没学到,那现在呢?就让我先剧透吧哈哈哈哈。
在编程上,TCP sockets和pipe都是操作文件描述符,用来收发字节流,都可以read/write/fcntl/select/poll等,不同的是,TCP是全双工的,pipe是半双工的,不方便。
就拿最快的IPC,shm共享内存来说,就那么好用?对于技术不过硬的朋友来说,那可真的是坑坑洼洼,反正我是鼻青脸肿了。 或许有人会说,具体问题具体分析,单机就用shm,分布式就用TCP,我想问问,有意思吗?有意思吗?就那么喜欢为一个功能写两份代码啊。 在比对一下shm与TCP,TCP是字节流协议,只能顺序读取,有写缓冲;shm是消息协议,一个进程把内容写入虚拟地址,由另一个进程来读走,基本上可以说是阻塞。
其实我是很喜欢shm通信的,甚至都封装了动态库,在我的“动态库”专栏下就能找到,但是吧,叛变就是这么的快哈哈哈。
再者,IPC通信崩溃会怎样?段错误;TCP呢?网络掉线,哪个好找?一目了然。 TCP一断掉,哪里断了哪里重连就好,IPC呢?那就得全部重头来过。
使用TCP长连接通信
使用TCP长连接通信的好处有两点:
- 容易定位分布式系统中的服务之间的依赖关系。
只要在机器上运行
netstat -tpna | grep : port
就能立刻列出用到某服务的客户端地址,然后在客户端上用netstat
或lsof
命令找出是哪个进程发起的连接。这样在迁移服务的时候可以有效的防止出现outage。 TCP短连接和UDP连接则不具备这一特性。 - 通过收发队列的长度也比较容易定位网络中或程序故障。在正常运行时,netstat打印的Recv-Q和Send-Q都接近于0,或者在0附近波动。如果Recv-Q保持不变或持续增加,一般是服务进程的处理速度变慢,可能是死锁或阻塞了。如果Send-Q保持不变或持续增长,那可能是对方服务器太忙,没空理你,也有可能是网络中某个路由器或者交换机挂了,甚至对方掉线了。
下面是个示例:
上一篇: 进程间通信的几种常用方法、通信特点和通信方法的优缺点
下一篇: 32.1 运行测试
推荐阅读
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。
-
您了解分布式系统进程间通信吗?