@zjp
面向 Socket API 学习 TCP 协议了解下...
说白了还是基础不扎实...

看了下那本《 Netty 权威指南》粘包相关部分的网络知识同样如此
另: 这篇文章其实就是相关章节的重写

@wysnylc
应用层无法简单获知 TCP 底层的包状态
事实上在系统内核做拥塞控制的时候就已经解包到字节流缓冲区了
既然给应用层的是字节流，那么自然不存在包的概念，更不可能粘起来。

(注意：极端情况下一次 socket read 调用会只获得一个字节的数据返回)

@wqyyy
还是有毛病...
这个解答显然这是面向 Socket API 学习 TCP 协议
正常情况下对方接收的时候根本无法预测能一次性的从缓冲区读取到多少数据
无法预测能读取到多少数据自然不可能有包的效果更不可能有后续的解释

提醒：TCP 是流传输协议

> 传输控制协议（英语：Transmission Control Protocol，缩写为 TCP ）
> 是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793 定义。
> （中文维基百科 TCP 词条 第一句）

理解了这个本质，那么**粘包**就不是一个问题
因为本来就没有**包**的概念，自然没有**粘**的可能性，更没有**粘包**这一说法

本质问题：如何在流传输协议上构造具有**可靠**分段特性的(包 /报文 /数据段)传输协议

硬件的开发流程

1、确定需求
2、依据需求选择方案（电源、芯片、模块、外壳工艺）
3、依据采购难度、体积、耗电、发热、成本等关系迭代需求进行取舍或增加功能
4、依据方案寻找有无开发板，如果没有自行开发一套开发板 /直接出成品电路
5、如果有参考设计，原理图的某些部分可参考参考设计，但总体来说需要配合产品本身进行开发
6、造外壳是与电路设计完全不同的一个领域，且与加工方的加工工艺紧密关联，务必准备足够的钱
7、上层应用的开发都是套路，最主要的硬件平台准备好了，应用开发就不是问题了(显然这是楼主最熟悉的)
8、如非必须，别踩驱动巨坑，如果需要进坑，聘人。。。

如果还能买到。。。K2P

@lyhiving #96
虽说一直都不信任任何云服务的可靠性，但经历了腾讯这件事，大概是不会把商业数据放上去了
毕竟有备份恢复起来也是很麻烦的...

@ryd994 #93
感谢信息分享

@songxinyingpg #95
请教，scrub 消耗磁盘性能的原因在哪里？

@zhuang
获益良多，感谢科普！

GPON 线路带宽 2.5G
EPON 线路带宽 1G

意味着，给你多拨的情况下只要你的总计带宽不超过 G 口带宽（也就是千兆）
一个光猫也是可以跑满的

zerotier

@webjin1
本来存储系统搭建的原则也是用最便宜的零件构造足够可靠的系统（虽说这个可靠是要看场合的）...
所以家用 NAS 从不推荐红盘、紫盘、黑盘、企业盘
（显然做不到这一点用高价零件的可靠性也是差不多的）

@zhuang #83
获益良多，虽说部分观点与现在的公告逻辑略有出入
毕竟按照公告说法，异常在源数据仓库不在目标数据仓库，写入异常不成立

关于疑问三其实是没想通为什么是一刀切形式的仓库切换
按理说所有在线的虚拟机都需要一个短暂的快照后增量同步的操作
或许这 3 分钟就是重定向 IO 后的增量同步过程吧。

但...三分钟时间内删除了源数据？不太敢想...

@nullornull

其实，题中的疑问心中早已有答案，虽说是依据现有的公告进行推测...
但没有技术资料的支撑，一切只凭经验，这样的答案显然是不适合写出来的，毕竟有失严谨...
最终发出一些对细节的疑问，让各位自行推测，也能在讨论的过程中相互学习增长见识...

总结的话大概是没有的，毕竟不同的人有不同的看法，不同的业务有不同的方案。

就事论事的讨论问题，并冷静的表述自己的看法，以理服人
在讨论过程中互相学习增长经验，这才是 V 站该有的氛围

@johnjiang85
疑问二其实是个商业问题，直接点说就是超售严重

至于架构上的问题，不能说运行多年相安无事就是合理且优质的
至少从这个事件上看，还有提升的空间

希望将来能有对应的技术分享
让我们可以深入了解云平台架构设计的前因后果
这也能让客户可以更加的放心

@jianpanxia 望科普！

拔掉一个 R6 阵列的 3 个盘......
ESXI 的母机操作系统挂了.....

@johnjiang85
问题泄露出来了底层架构的不合理, 加紧改善吧....