romandion的专栏

        对服务器程序来说，有两个基本假设十分重要，究竟服务器是基于状态请求还是无状态请求。状态化的判断是指两个来自相同发起者的请求在服务器端是否具备上下文关系。如果是状态化请求，那么服务器端一般都要保存请求的相关信息，每个请求可以默认地使用以前的请求信息。而无状态请求则不行，服务器端所能够处理的过程，他的处理信息必须全部来自于请求所携带的信息以及其他服务器端自身所保存的、并且可以被所有请求

【1】、开发背景上篇已经提到了CST设计的背景，这边来介绍下整个系统的规划。由于，还在设计原型阶段，所以变更再所难免。CST脚本语言的开发计划的提出，主要为了解决在高性能服务系统中，业务逻辑的变更和快速开发的问题。本次CST脚本将直接应用于风控推送模块。【2】、特性和价值A、脚本语言B、嵌入式C、高性能D、联合器E、C语法F、精炼简单 CST基本语言本身是一

 我在很多场合论述了脚本语言的重要性，分析过各个语言的特性。由于自己主要做C/C++开发，所以对嵌入式脚本语言，如Lua比较推崇。现在由于工作的关系，准备设计一种脚本语言，类于c语法。先介绍下设计背景。在很多系统设计的背景下，特别是我正在从事的服务系统设计，性能是很重要的考量，所以c/c++是首选的。但涉及到很多业务逻辑，却是容易变更和增删的，使用c/c++来应对这种业务逻辑是很辛苦的，因此，

 虚拟机执行速度缓慢，好像和高性能没有什么关系，但事实上，却不是这样的。我们首先探讨下对高可用的作用，这个其实比较好理解。虚拟机一直执行脚本化程序，比如lua/ruby/python/sql等，他们在虚拟机中被解释执行。java其实也可以被认为是这样的，erlang也是。这些情况都反应了这样的事实，当然，我们并不是说他们都是高可用的。我们考察2个重要的语言：SQL和erlang。SQL是一种结构化

C/S架构中，最常见的就是请求->处理->应答。高可用高性能系统的架构设计中，对这块有一定要求，而且是很重要的要求。如果一个请求很容易被接管转发，那么就能很方便地设计分布式计算，或者负载均衡。所以，我们在这块架构设计中，希望对请求进行一定地设计，减少请求之间的依赖，同时保证请求和应答之间足够快速。这样就能够提高并行度。所以，处理粒度就成了很重要的因素。在GOOGLE的一篇MAPREDUCE论文

   故障检测是高可用系统中的一个重要内容，它是系统高可用的基础，只有故障能够被及时准确的检测出来，才谈得上高可用。心跳检测是常用的检测方法，它被广泛地使用于各种系统，虽然心跳检测有很高的适用范围，但是它有很大的局限性，包括滞后性以及其他因素的影响，比如CPU忙或者网络阻塞的因素。   其实我们知道，心跳的目的只是想知道故障的结果，而不需要知道故障的原因和现象，但是故障的发生并没有

    进程是系统的一个处理单元。系统的处理单元按不同的粒度来划分的话，可以是函数、线程、进程、计算机、集群。当然，进程仍然是最基础的操作系统的处理单元。当系统发生一个无法恢复的错误时，操作系统一般都是以进程为单位，将其杀死，同时释放该进程的资源。函数，线程在处理致命性错误传播时，多数是无能为力的，即使有C++异常捕获系统这类东西。    我们讨论进程如何在实现高可用高性能，对其他粒度的讨论是有作

    虚拟网在这个系统中作用是为了能更好控制请求和响应的处理。象DNS等标准的互联网组件来说，我们没有办法控制，但如果我们建立自己的虚拟网，那么就完全可以实现自己的DNS。象很多以DNS来实现负载均衡的系统来说，在这里都是很容易实现，当然这不是主要的考虑因素。    我们假设有一个服务失效了，那么我们的传统做法如何处理呢？如果是通过DNS来实现负载均衡的话，实际只能删除改服务的IP，防止新的

在高可用性的要求下，理论上要求所有的数据、载体都必须有备份，这样就可以避免单体故障的影响，这是最基本的要求。如果在简单的系统中，这没有问题，毕竟2台或者少数的几台基本上没有什么问题。可是我们如果想象下GOOGLE那样的公司，或者大型的券商或者交易所啥的公司。双备份的要求可能会变得难以承受。其实我们研究下双备份的缘由，可以发现，之所以要双备份，主要是希望在其中一个系统失效的情况下，另外一

    UDP对实现高可能高性能系统有啥好处呢？其实UDP的好处是间接的。我们知道UDP和TCP不同的是，UDP不保证可靠性，他只管发，不管收没收到。也就是说一个报文，他只会发一次而已。而TCP就必须靠复杂的机制保证可靠性。而且，UDP还具有广播，可以一次让多台机器收到报文，如果靠TCP的话，就必须发多次，性能上，当然差别很大了。    以上只是简单介绍下UDP的特性，下面我们来引入实际的例子。我

   关于状态还是无状态这2种服务器架构，我在以前的一篇文章：《状态和无状态－－2种服务器架构之间的比较》http://blog.youkuaiyun.com/romandion/archive/2007/09/25/1800025.aspx   做了论述，也涉及到高可用高性能方面，现在想做一些补充。一、核心区别   每个服务器的架构，通常可以简化为请求和应答的过程，状态化和无状态化的最核心区别在

    首先必须申明，这不是个路由器，而是借用路由器的特性。一般说来，传统的路由器，将IP包转发到目标机器上，那么他的路由规则就是IP地址。但对服务请求来说，可能是SQL语句或者其他具有规则特性的请求。我们可以建立一个服务，按照一定的规则，将这些请求分发到其他服务上去，就像路由器转发IP包那样。这个路由服务主要的功能就是按规则分发，但他可以也可以不需要处理请求的结果数据。对于接收到请求的服务来说完

   分布和集群不完全一样，但有很多相似的地方，也有很多不同的地方。我们主要从他的基础特性上来分析，分布的计算单元可能分布在广大的地理空间，比如中国的一台机器和美国的一台机器；而集群的计算单元主要集中在一个相对较近的距离，比如一个机房，对于集群的使用者来说，集群是个整体，他的构成是透明。不论他们是为了完成同一个任务还是分担不同的任务，我觉得都不是关键问题。他们之间最大差别就是计算单元之

一、网络故障    当客户正在交易时，突然网络发生异常，导致无法继续连接到网络上。这个场景是最可能发生的。我们需要在网络发生的时候，让客户能够继续进行这个交易。二、性能故障    由于机器性能或者软件性能的缘故，可能会导致我们在某个业务处理过程中耗费大量时间，比如数据库查询。但是这也不应该影响我们进行继续交易。三、系统崩溃    一个畸形的请求，让我们的系统在某个不完善的地方发生了崩溃，这个很可怕

     高可用系统必须对故障具备很高的容错能力，而这核心问题就是对故障的管理。从系统组成来看，故障可能是整个系统的，或者某个组件、某个服务甚至某个进程中发生。对故障的管理可以分为几个过程：检测、定位、隔离、恢复、报告。如果继续强化的话，还应该加入预测功能。    故障的检测主要工作是检测系统中在某个单元是有故障发生。故障的定位主要是判断这个故障发生在哪个单元以及这个单元具体在哪个位置。故障隔离是

   建设一个高可用高性能的系统是我最近几年的努力目标，但其中涉及的内容颇多，都是些零星的经验，缺乏系统性架构总结。写这个系列的文章其实是我一直以来的想法，不过题材和内容过多，所以一直搁置。前些日子到一家公司面试，备受打击，觉得有必要把它总结一下。    我假定要为期货交易建设一个高可用高性能的系统，那么期货交易就是系统应用场景。期货交易的诸多规则我们没有必要理会，我们只需要简化出一个交易场景，需

最近在研究银期系统，涉及到交易系统、结算系统、银行系统多系统的资金一致性问题。按通常的做法，导致系统复杂性难以控制，需要一种简洁的解决方案。