Hello,World! Here is my personal weblog about technology and life.
看到的很好的解释零拷贝的文章，大量优质图示很好理解，写的真是不错啊，转载转载。。
原文转载自微信公众号「后端技术指南针」，作者指南针氪金入口。
扩展阅读:
像大白这种调包侠，深知不懂底层技术点就如同空中楼阁，再这样下去面阿里p10是没希望了。
想到这里，我开始慌了，所以今天和大家一起学习个底层技术点-零拷贝Zero-Copy。
Linux系统中一切皆文件，仔细想一下Linux系统的很多活动无外乎读操作和写操作，零拷贝就是为了提高读写性能而出现的。
废话不多说，马上开大车，走起!
在Linux系统内部缓存和内存容量都是有限的，更多的数据都是存储在磁盘中。对于Web服务器来说，经常需要从磁盘中读取数据到内存，然后再通过网卡传输给用户：
上述数据流转只是大框，接下来看看几种模式。
软件之难，不在于技术而在于工程;
工程之难，不在于流程而在于组织;
组织之难，不在于管理而在于文化;
注解：
现代软件大多通过开源组件的堆叠组合形成，软件实践中的技术问题可以大多通过找寻资源得到解决，技术已经不是现代软件开发工作中的难点。软件的工程学要求我们把软件作为工程去建设、管理和维护，这涉及到项目的架构设计／演进、项目各生命周期管理等多学科交融知识，是一门复杂而有难度的工程学实践活动。
工程的难度不在流程，流程是可以固化的、一尘不变的死的东西，影响工程的是组织架构。康威定律告诉我们，一个好的工程需要一个健康的组织架构，好的组织反哺软件，坏的组织结构则破坏软件。
组织的难度不在于管理而是文化，文化是企业的基因，没有好的基因就没有好的政策，就得不到好的组织，就做不好工程，就没有好软件！
华为从ict起步，如今消费者bg业务蓬勃发展，公司的愿景是万物互联，需要每一代华为人奋斗不息
勇于改变，应对挑战
工作中不要只盯着PBC，多做一些”无关”的小事
登山的团队中，人们都会带一些小西红柿牛肉干等小零食（苹果、梨子不好与人分享），从而拉近彼此的距离
设计玄关时需要考虑“要让住的人如何脱鞋，鞋子放在哪里”。
门要配合人的移动，内开是原则，卫生间空间不足可以设计为外开，玄关的门（大门）一般也外开。
卫浴间干湿分离的三种布局：半开放式、独立式、实体墙式。
弄清烹调的顺序来设计，如下
窗户或门，通风口或维修口，住宅墙面内外各式各样的洞，建筑学上统称为“开口部”。
门的作用是通行（配合窗户通风），开窗目的是视野、采光和通风。开口部的设计不仅要考虑“让什么通过”也要考虑“不让什么通过”，才能设计好门窗类型。
导读：开源精神是技术发展的源动力之一，受到工程师们的热烈欢迎。但是开源项目如此之多，哪一个最适合自己？如何更好利用开源项目，甚至做二次开发？今天，阿里资深无线开发专家李运华，总结多年与开源项目打交道的经验，讲述如何正确利用开源项目，希望对大家有所启发。
软件开发领域有一个流行的原则：DRY，Don’t repeat yourself，我们翻译过来更形象通俗：不要重复造轮子。开源项目主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目，可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？
然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分同学都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万数据，甚至灾难性的事故是全部数据都丢失。
除此以外，虽然DRY原则摆在那里，但实际上开源项目反而是最不遵守DRY原则的，重复的轮子好多，尤其是歪果仁，一看哪个开源方案不爽，自己就吭哧吭哧搞一个差不多的：你有MySQL，我有PostgreSQL；你有MongoDB，我有Cassandra；你有memcached，我有redis；你有Gson，我有Jackson；你有Angular，我有React。总之放眼望去，其实相似的轮子很多！相似轮子太多，选择就是让人头疼的问题了。
怎么办？完全不用开源项目几乎是不可能的，我们需要更加聪明的去选择和使用开源项目。形象点说：不要重复发明轮子，但要找到合适的轮子！你开的是保时捷，可别找个拖拉机的轮子。
接下来我将根据加入UC，5年与开源项目有关的经历，总结出一些“如何正确使用开源项目”的经验和教训。有的项目是我亲身经历，有的是我接触到的，有的是我观察的，其中部分描述细节可能并不完全准确，大家可以结合自己的经历一起探讨。
以下内容主要分3个部分进行描述，分别是“选”、“用”、“改”。
我们在选择开源项目的时候，一个头疼的问题就是相似的开源方案较多，而且后面的总是要宣称比前面的更加牛逼。我们在选择的时候有点无所适从，总是会担心选择了A方案而错过了B方案，或者反过来。这里我们的经验是聚焦于是否满足业务，而不需要过于关注开源方案是否牛逼。
案例：当时尝试一个社交类业务时，我们发现了TT（Tokyo Tyrant）这个开源方案，觉得既能够做缓存取代Memcached，又有持久化存储功能，可以取代MySQL，很牛逼，很高大上，于是就在业务里面大量使用了。但后来的使用过程让人很蛋疼，主要表现为：
1、不能完全取代MySQL，因此有两份存储，设计的时候每次都要讨论和决策
2、功能上看起来很高大上，但相应的bug也不少，而且有的bug是致命的，例如所有数据不可读，后来是自己研究源码写了一个工具才恢复了部分数据。
3、功能确实牛逼，但需要花费较长时间熟悉各种细节
后来我们反思和总结，其实当时的业务Memcached + MySQL完全能够满足，且大家都熟悉，当时的业务完全不需要引入TT。
简单来说：如果你的业务要求1000 TPS，那么一个20000 TPS 和50000 TPS的方案是没有区别的。有的人可能会担心我TPS不断上涨怎么办？其实不用担心，我们的架构会不断演进的，等到真的需要这么高的时候我们再来架构重构，记住：不要过早优化，过早优化是万恶之源 —— 《UNIX编程哲学》
