romandion的专栏

重新设计网络库接口，这个非常重要。一则对应用层足够简单友好，二则确保底层能够实现低延迟。网络库实现可以分为两个大的部分：1、网络收发，这个容易理解，但对系统底层依赖较高。2、进程内分发，这个容易被忽视，但在纳秒级网络库中，同样非常重要。qkitc项目，主要实现进程内分发。一次echo收发，延迟从前一版本的2微妙降到当前版本的500纳秒，可以接受。

https://github.com/QuarkCloud/quark-daemon.git发布的第一个版本作为基准。虽然没有实现我们最终的目标纳秒级网络库，但是大部分思想已经具备，后续将继续调整和优化。

在十年之前，已经有网络产品实现7纳秒延迟，所以无需质疑是否能够实现，关键问题是：代价是什么。

硬件和软件技术在近几年发展神速，但在大众的视野中，网络技术仍然停留在十年之前，这一波技术红利并没有得到充分的应用。

在物理核上，主要有L1和L2高速缓存，L3高速缓存目前是片内共享的，即整个CPU内部共享的。更早之前，L2和L3是集成在主板上。L1高速缓存被拆分成L1d和L1i，即数据缓存和指令缓存。

和所有基于Broker总线一样，qpid本身架构是联邦制的总线集群，这意味着，一份数据需要在多个broker之间互相备份。这个架构是AMQP定义的，本身并没有什么问题，因为AMQP是为交易而生的，对数据准确可靠的要求远远超过对性能的要求。我们看到在很多公有云中，也经常使用AMQP的另外一个实现RabbitMQ。和qpid一样，这两者之间基本可视为等价，知识每个供应商有所偏好，但各项指标...

在写下其他文字之前，必须先声明下，这篇文章不是介绍讨论关于分布式技术的，而是讨论分布式架构在微服务架构中的价值和弊端。分布式技术经过多年的发展，已经相对很成熟，相关文章很多，所以不是本文的重点。在阅读下文之前，我推荐先阅读以下三篇文章，特别是最后一篇，有比较完整的阐述。http://2012.33degree.org/pdf/JamesLewisMicroServices.pdf htt...

http://dongxicheng.org/search-engine/kafka/1、  概述Kafka是Linkedin于2010年12月份开源的消息系统，它主要用于处理活跃的流式数据。活跃的流式数据在web网站应用中非常常见，这些数据包括网站的pv、用户访问了什么内容，搜索了什么内容等。 这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。传统的日志分析

http://www.infoq.com/cn/news/2013/03/linkedin-databus去年的架构师峰会上，来自LinkedIn的高级软件工程师Lei Gao做了一场名为《LinkedIn的数据处理架构》的演讲，着重介绍LinkedIn内部的数据基础设施的演变，其中提到Databus数据总线项目，当时就引起大家诸多好奇。前不久，LinkedIn工程团队官方博客发布

在众多对google protobuf赞美中，提示protobuf存在问题有点不和谐。但我们应该在众多美好描述之中看到它的不足之处，才能更好地将它应用在合适的场景下。protobuf的困局核心在于他type失去了扩展空间。