| 若要统计开发部的口语中出现频率最高的词条，名列前茅的恐怕当属"发包"、"丢包"、"连接"、"Socket" 这些个词了。每当调试、测试程序，"丢包"是老生长谈、众矢之的。当客户打来电话时，“丢包”是个充满牢骚味儿的词儿。▲▼平台自 1.11 --> 2.7 这 28 天里，日平均丢包数为9-10个（新老数据比较）。从 2.8 至今，"丢包"这小滑头又不知藏哪去了？好象一切又恢复了平静。这种平静并不令人放心，谁能保证它不会东山再起呢？相关人员都琢磨在哪个环节还隐藏着差错。说什么也得把异常基因给纠正过来。产品"信得过"是大伙的衣食父母，是立足电子商务之本啊。"包"怎么会丢的？收不到回包，通信出了问题：连接失败或者连接断了。我们系统全靠消息包在公网和局域网上按指定路线准确地"旅游"，业务流程才得以实现。为什么偶尔会出现"连接不上"或"连接断了"？排除硬件故障后，自然会在软件环境和设计上问几个为什么？现在"丢包"发生在货架产品通信服务器和应用服务器之间，两者都通过通信底层软件进行通信。从接入发来的计费包进入管理平台后,第一站是通过通信服务器，再发往应用服务器AppServer,如果一切顺利，就会在两个服务器之间建立起一个能长久保留的 Socket（公司俗称这种连接为"死连接"），如果这个"丝绸之路"不夭折，后续计费包则可通过该通道"鱼贯而入",但如果后续消息包到达超过一分钟，例如某个计费包姗姗来迟，则接收方的通信底层认为发生了"不测风云"，会主动把Socket给关掉了。这一来通道只能"寿终正寝"了，因为握手的一方已经把手缩了回去。这是设计者预料中的事，能期望用户会挨个排队拨打179访问我们的平台吗？通信服务器订了接待规则，那些慢慢抵达的消息包也不会受到冷遇。设计师会已经断掉的连接再建新的"青藏公路"。在设计者的心中，已经把工作做得尽心尽力了。在 1.11 --> 2.7 的日子里，"丝绸之路"或"青藏公路"在绝大多数时间里都无可挑剔，可是每天都有那么十来次不能及时修复而引起"扔包"。再建Socket为何失败呢？初步分析是AppServer这一方"腰肌劳损"，累了。是累积引的起资源紧张。有人说"内存泄露"，有人说"负担过重"（与Sybase共枕）,"装备不良"（需加大内存），也有人说是瞬间进程内堆（栈）资源达到满负荷（共十来个进程）......无论如何，是个应该找到答案的技术问题。作为以"连接"、"发包"为基础支撑技术的公司，应该把相关技术和理论搞透。提个经不起推敲和也许可笑的建议吧：为什么AppServer不设计成对计费来包给出返回包，告之ZZcom"我是长连接,不要关掉我"，呢？ |