romandion的专栏

网关主要面向互联网，技术核心就不是怎么将延迟降到微秒级别，没有意义，而是在处理好不稳定的网络状况后，保证业务的持续性。

以股票行情为例，讨论在内存中应该如何设计低延迟的内存数据库。

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

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

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

高性能服务系列的核心关键是减少等待时间，提升有效的CPU时间。假设一切都是正常的，没有低级错误，那么影响性能的几个因素，在之前几个篇章都提到过，这里做下总结。

主题匹配核心算法就是字符串匹配，虽然是体现在应用层面上，但该算法效率最终会影响到服务性能，所以仍然有讨论的必要。

无锁结构本身就是为了提高性能，减少多线程互锁切换，导致的性能损失。因此，基于固定长度数组实现的无锁队列最为流行。无锁队列对于多读多写的算法虽然十分复杂，但原理可以从自旋锁进行推演出来。

反向代理和网关一样，是内外网的一个重要边界，通常运行在传输层之上的应用层。所以，性能就会受到两个重要因素的影响，网络IO和应用层编解码性能。如果将nginx作为内网的API网关，那么就是另外一个考量，现代网络传输技术，对其有巨大的加成。

现代网卡已经普遍支持10Gb，100Gb也不少见。为了解决C10K问题而提出的多路复用iocp/epoll解决方案已经无法提升性能的需求。内核TCP/IP协议栈延迟的占比就凸显出来，内核已经不是解决问题，而是问题本身。C10M时代已经到来了。

在网络中，点到点的延迟，最大因素是物理距离。其次是RTO，超时重传。还有滑动窗口和拥塞控制算法。在高速网络中，比如40Gbps，甚至100Gbps的网络，网络传输速度已经和芯片内部的传输速度相差无几，对程序提出更苛刻的要求。

网卡标注的是物理层比特流速度，并不是网络层的网速。要计算应用层的有效载荷，先根据网速计算出PPS，再扣去以太网帧，链路层，IP层、TCP层这些固定损耗，就能得出每个数据包最大和最小有效载荷。对于TCP稍微要麻烦点，因为有些ACK包，还有重传包，同样也会消耗掉有效载荷。

进程是操作系统管理分配资源的基本单位，线程是操作系统调度CPU的基本单位，进程之间，是没有直接关系的。所以，一个进程的崩溃不会影响到另外一个进程的运行。基于这个特性，在追求高可靠的系统中，往往会采用多进程模型。

线程之间同步采用互斥锁的粒度太大，容易导致等待，以及上下文切换。再后来又出现读写锁，减少锁的几率。自旋锁这种更低粒度的锁，避免线程切换的同时，也能避免内核态和用户态的切换，减少性能损失。

随着现代服务器主板上挂载的CPU越来越多，一个很显然的限制，就是FSB和北桥芯片的带宽跟不上，于是NUMA架构被提出。NUMA的几个特点，就是为了解决FSB和北桥芯片的瓶颈问题。

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

从最基础的硬件开始，到操作系统，到线程、进程，再到网络，顺带磁盘存储。以这些内容为基础，扩展分布式系统。中间穿插讲解一些关键技术的理解。

稳定性，通常是以可靠性来衡量，即我们常说的几个9，这个主题在之前各个系列文章中已经提到过，本来没有打算单独写一篇。前几天一个老同事在群里发出一个灵魂之问，“如何解决生产环境更新系统后的稳定性问题”。因此，觉得有必要再专门就这个主题做一个论述，也考虑这个主题内容实在太多了，以列举核心内容和纲要为主。在所有论述之前，必须深刻认识到两个核心原则：1、任何系统都会出错。要将可靠性从99%提高到99.9%，虽然只提高0.9%可靠性，但故障率降低了10倍，研发成本需要慎重考虑，极大可能也是要增加10倍。2、

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

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

http://www.romandion.com/Program/program001.htm一、前言     由于系统不稳定，经常要重装DELPHI。而每次安装DELPHI的时候，原来注册的组件都被刷新，只能重新安装组件。众所周知，DELPHI的第三方组件N多，这个安装着实令人头疼。更有甚者，因为某些莫名其妙的原因，DELPHI的组件面板

http://www.romandion.com/Program/program002.htm在DELPHI中，许多组件都是以BPL、DCP的形式出现的。某些优秀的组件，特别是国外一些优秀的组件，出于版权的考虑，没有提供DPK和PAS的源码，而仅仅有BPL、DCP、DCU、DFM等二进制形式提供。出于业务的需要，有时候需要将组件直接呈现给用户，但是英文版的组件直接提供给用户，那么很郁闷的事

　转载自 www.romandion.com 一、开发技术的成熟          当计算机刚被发明不久的时候，只有极少数人能够接触到计算机，更别说是软件开发。计算机是如此神秘，以至于在大多数人看来，那是天才的玩具。但是，随着个

      转载自： www.romandion.com 　　《设计模式》这本书被许多人奉为一个经典的作品，他让新人更快加入到专家的行列中去。正如作者所提到的那样，复用以前使用的方案是成为专家的部分原因。模式描述的是一个重复发生的问题以及该问题解决方案的核心，作者以一个文档编辑器的实例引出3大类23小类的设计模式，如下所示。

一、前言       关于你所提到VCL framework/Object pascal/windows SDK/Com，这些在Delphi的帮助都有提到，我想你之所以提到这些，是希望了解我对Delphi理解的深度和广度，基于这个认识，我在这里阐述一 下我对Delphi的认识。

 序言     这个文档是我为一家公司安装jabber-2.0s11服务端系统而写的文档，目的是为了帮助他们维护人员更方便的安装、部署服务端。要安装至少要先满足下面几个条件：（1）、Red Hat Enterprise As 3（2）、glib 2.0+  （3）、Apache Http Server 2.2 1         Jabber 服务器部署详细说明

sysctl.conf 是由/etc/rc.d/rc.sysinit在系统初始化是调用的参数列表。下面的参数列表可以通过sysctl -a输出abi.fake_utsname = 0abi.trace = 0abi.defhandler_libcso = 68157441abi.defhandler_lcall7 = 68157441abi.defhandler_elf = 0abi.defhan

        曾经看到一个很多意思的代码，它的大概目的是用一个宏来同时替换一个结构的成员同时产生一个字符串，如下例：                #ifndef  __EXAMPLE_H        #define  __EXAMPLE_H 1       typedef struct example_st{            char name[1024] ;      } examp

    跨平台编程是个很有意思的工作,研究Apache的架构有段时间了,对他跨平台的手段有一定的理解.    Apache跨平台的基础主要分为2种情况,一种是不同的操作系统,另外一种是不同不同编译器.在Apache有少部分的代码是和汇编指令有关的,这部分只占很少的一部分,而且主要是集中在APR库中,比如ATOMIC代码,基于代码效率考虑,有些是直接使用汇编代码的.   下面我们主要集中介绍Apac

对于一个软件来说，一般都会碰到几种广义上的平台特性，特别对于跨平台的网络程序来说。 1、硬件指令环境：比如说英特尔、摩托罗拉等芯片机器指令都有所不同 2、操作系统环境：不同操作系统或者同一操作系统的不同版本都存在需要兼容的特性 3、编译软件环境：现在很多IDE都不一样，即使象C++这样具有统一标准的语言，都会被相应的扩展 跨平台方案首先要解决这3个问题。一般来说，我们写的都是应用级别的软件，硬件

         写程序的时候，输出调试信息是非常重要。在C中，我们常常使用printf，而在C++中，标准的用法是cout的了。有些比较老道的做法是加个DEBUG宏，比如：        #ifdef  __DEBUG__        printf("hello world") ;        #endif       这个办法在早期时候，用的比较多，他很容易将__DEBUG__宏去掉，就不

一、重要性      日志系统在整个系统架构中的重要性可以称得上基础的基础，但是这一点，都容易被大多数人所忽视。因为日志在很多人看来只是printf。在系统运行期间，是很难step by step的，所以只能根据系统的运行轨迹来推断错误出现的位置，这往往也是唯一的资料，特别是在高可靠性的情况下。      从更大方面的范围来说，日志系统是运营维护的范畴。但小的方面来说，这是必须的调试的手段。在多年

1.recv返回EILSEQ错误，POSIX规范中没有描述，郁闷。EILSEQ的描述完全摸不着头脑，先记着。2.list.push_back发生coredump错误。还不知道啥原因。

五、日志控制    1、控制目标    日志系统要控制的目标包含整个日志内容流转的过程。对日志来源的控制，一般着重于对日志内容的过滤。上面对内容进行分级、分类、制定格式，一个最重要的原因就是对日志内容的过滤。对日志输出控制，主要着重于输出目的，比如是文件还是SYSLOG，以及诸如此类。    日志控制是日志内容流转过程中的一个强化功能。一般来说，越多的日志内容，对系统跟踪分析更有利，但更多的内容，

一、errno的由来    在C编程中，errno是个不可缺少的变量，特别是在网络编程中。如果你没有用过errno，那只能说明你的程序不够健壮。当然，如果你是WIN32平台的GetLastError()，效果也是一样的。    为什么会使用errno呢？个人认为，这是系统库设计中的一个无奈之举，他更多的是个技巧，而不是架构上的需要。我们观察下函数结构，可以发现，函数的参数返回值只有一个，这个返回值

#define printf(format , ...)  printf("FILE[%s] LINE[%d]" format , __FILE__ , __LINE__ , ##__VA_ARGS__)这个宏应用好几个技巧：1、使用printf宏，和原来的printf相同。这样我们不需要修改源码，直接替换原来的printf的函数。2、使用__VA_ARGS__宏，直接使用可变参数3、使用"FIL

下面是 Makefile.am中的代码，蓝色部分是一种扩展，将生成出来的静态库拷贝到lib目录：noinst_LIBRARIES=libutil.alibutil_a_SOURCES= util.call-am: $(all-am) CPLIBRARYCPLIBRARY :    cp $(noinst_LIBRARIES) $(top_srcdir)/lib上面代

    在C语言中，返回码是很重要的值。和其他支持异常的语言，如C++不一样，C主要还是通过返回码来判断是否执行成功以及发生错误的原因。在POSIX规范中，定义了全局唯一的错误码，当错误发生时，errno指示出错误的原因，而返回码以-1或者NULL等畸形值来指示错误的发生。但是这同样有个问题无法解释，就是发生错误的确切位置。    我重新尝试在返回码中添加错误发生位置的信息，如行号。但却没能指出错

    行级锁是比较高级的功能，在各个操作系统都有提高，但没有统一标准。在POSIX规范中，提供一个文件级的锁，本文就是提供一种方案，利用文件级的锁来实现行级的锁。    有人会觉得这个没有什么必要，因为可以直接调用操作系统的接口。这样也可以，不过由于POSIX和标准C库是跨多个平台，我们利用标准库的接口来实现，就不会有平台的问题。如果在性能方面要求不是太苛刻的话，这个方案实际上相当不错。这个方案

一、问题的描述    链表由于各个元素之间是通过指针方式连接在一起，所以增加删除都非常方便，但是在随机访问却远不如数组。数组的下标是可以通过算法直接定位的，但链表却不行。二、问题的方案    我们定义一种组织方式，以链表为基础，但是将相连的若干元素组成一个簇，和一个节点相关联。这个节点只负责管理链表元素的指针头部，和这个簇的所有元素的数量。当链表增加删除元素时，可以通过改变节点所记录的簇的头部和簇