zeromq解决了什么问题

很早就听说了zeromq 这个项目,当时不太在意后来同事kasicass 对这个项目做了研究和分享 ,开始重视起这个项目来1) libevent封装了对网络I/O,信号,定时器等的处理,可以基于它之上做网络层的开发2) ACE封装了不同平台下的系统调用,也提供好几种网络编程的模型然而,zeromq不是libevent,也不是ACE,因为它的主要特性是:面向消息进行通信所以,它提供的是比libevent,ACE处在网络通信中更高一层的组件使用它,程序员不再需要上面提到的libevent,ACE之类的库需要关心的东西,程序员如果要使用zeromq,只需要做如下的事情:1) 告知所使用的patten,比如request-reply,pub-sub,push-pull等(下面会详细解释这个pattern)2) 告知是用于机器之间,还是进程之间,线程之间的通信然后,将所需要发送的数据封装到zeromq自带的msg结构体中发送出去,使用者自己关心如何序列化/反序列化这些数据,然后如何处理这些数据就是使用者的事情了这样看上来,使用者要关注的事情”高”了一层,大部分的精力都可以放在业务逻辑之上了简而言之,它让使用者的精力放在了通信模式和业务逻辑上,而不是更下面一层的网络层上下面解释一下zeromq常用的几种网络pattern:1) request-reply就是一般的C/S架构中,client与server之间一问一答的通信模式,比如最经典的echo服务需要注意的是,client发送一个request,server必须有一个回应server端作为publish端,而任何连接到服务端的client都会成为subscribe端也就是说,server端会把当前的所有需要publish出去的消息全部发送到当前连接上去的client上3) push-pullserver端作为push端,而client端作为pull端如果有多个client端同时连接到这个server,则服务器会在内部做一个负载均衡,采用平均分配的算法,将所有的消息均衡发布到client端上看上去,很稀松平常接下来亮点真的来了考虑如下一种场景一个server端做为一组服务器集群最上层的一个proxy,起到负载均衡的作用,将请求按照它下面对应服务器集群依次派发到不同的 client端进行处理某个时刻可能处理的机器只有2台,而随着负载越来越大,可能需要3台机器了,这个时候如果使用zeromq的push-pull 搭建的proxy端,则可以不用对之前搭建的server,client端进行停机,只需要新启动一个client连接上去,proxy层就会自动根据当前的机器分配平均派发任务了cool实际上,这些模式并不是什么新东西,只不过zeromq为使用者做了一个封装,而不是像libevent,ACE等还局限在网络层部分的封装,它关注的是通信层,通信模式等个人感觉,zeromq部分解决 了erlang所要解决的问题:在多台机器中通信,派发任务等,是分布式通信的利器,但是局限于语言的限制,它没有办法做的跟erlang一样的完善(erlang已经可以算的上一个简易微型的OS了),但是许多的时候,似乎只使用这一部分功能也就足够了zeromq的代码量,截至到我目前阅读的2010-stable版本,也只有不到2W行代码提供出去的API也极为简单,但是内部的实现比较”绕”,zeromq是我阅读过的项目中少数的非常需要依赖调试工具跟进代码才能看懂代码流程的项目,同时代码中类的继承层次也比较多,阅读起来并不像它提供的API那样简单直白后续会对其中的一些难点做一些分析

java架构师需要学习JVM、数据结构和算法、设计和架构等等。java架构师的平均月收入在15000左右。

java架构师需要学习的知识

1、JVM：多线程与并发、GC（GC收集器类型、算法、分区）、IO类型（同步阻塞、同步非阻塞、基于信号、多路复用、异步IO）、类加载

2、数据结构和算法：搜索（二分）、排序（选择、冒泡、插入、快递、归并、堆、桶排序、基数）、高级算法（贪婪、回溯、剪枝、动态规划）、大数据算法（hash分桶、统计）

3、性能优化：分层优化（系统级别、中间件级别、JMV级别、代码级别）、分段优化（前端、后端、资源）

4、设计和架构：设计模式、架构方法论、设计案例、UML

5、中间件：数据库（mysql、oracle、db2）、缓存（Redis、mencache、tair）、消息队列（JMS、Kafka、RocketMQ、RabbitMQ、ActiveMQ）

java架构师的薪资待遇

工作经验不同，java架构师的月收入也就不同。应届生月收入在8000左右，有1-3年工作经验的java架构师的月收入在10000左右，有3-5年工作经验的java架构师的月收入在20000左右，有5-10年工作经验的java架构师的月收入在30000左右，有10年以上工作经验的java架构师都是赚取年薪的。

想成为高薪的java架构师并不是一蹴而就的，需要很多经过实战历练，要有扎实的技术开发能力和丰富的项目管理经验。如果未来你想成为java架构师，一定要在做程序员时期对自己有严格的要求。并且通过学习不断的充电，提升自己的综合能力，只要平时多用心积累经验，要最短的时间内实现跨越式提升，成为java架构师。

java架构师的工作不是一般掌握点java技术的就能胜任的，成为java架构师之前必须是高级java工程师，一个java架构师除了要具备高级的java技能之外，还必须有超强的需求分析能力、沟通协商能力、框架建造能力、决策能力等等。

RocketMQ单机可以支撑10万+的并发访问，集群部署可以让流量分散在多台机器上来支撑高并发。

MQ会收到大量的消息，并不是立马就会被所有的消费方获取过去消费的，所以一般MQ都得把消息在自己本地磁盘存储起来，然后等待消费方获取消息去处理。

本质上RocketMQ存储海量消息的机制就是分布式的存储。所谓分布式存储，就是把数据分散在多台机器上来存储，每台机器存储一部分消息，这样多台机器加起来就可以存储海量消息了

Broker主从架构以及多副本策略，Master Broker收到消息之后会同步给Slave Broker，这样Slave Broker上就能有一模一样的一份副本数据。即使Master出现故障，还有Slave上有一份数据副本，可以保证数据不丢失，继续对外提供服务，保证了MQ的可靠性和高可用性。

RocketMQ为了解决这个问题，有一个NameServer的概念，他也是独立部署在几台机器上的，然后所有的Broker都会把自己注册到NameServer上去，对于系统而言，如果他要发送消息到Broker，会找NameServer去获取路由信息，就是集群里有哪些Broker等信息如果系统要从Broker获取消息，也会找NameServer获取路由信息，去找到对应的Broker获取消息。

NameServer支持部署多台机器的，起到高可用的效果，保证任何一台机器宕机，其他机器上的NameServer可以继续对外提供服务。

每个Broker启动都得向所有的NameServer进行注册也就是说，每个NameServer都会有一份集群中所有Broker的信息。

系统自己每隔一段时间，定时发送请求到NameServer去拉取最新的集群Broker信息。

在RocketMQ的实现中，采用的是 TCP长连接 进行通信。 Broker会跟每个NameServer都建立一个TCP长连接 ，然后定时通过TCP长连接发送心跳请求过去靠的是Broker跟NameServer之间的心跳机制，Broker会每隔 30s 给所有的NameServer发送心跳，告诉每个NameServer自己目前还活着。每次NameServer收到一个Broker的心跳，就可以更新一下他的最近一次心跳的时间。然后NameServer会每隔 10s 运行一个任务，去检查一下各个Broker的最近一次心跳时间，如果某个Broker超过 120s 都没发送心跳了，那么就认为这个Broker已经挂掉了。

如果Broker挂掉了，那么作为生产者和消费者的系统是怎么感知到的呢？有两种解决办法。

首先，你可以考虑不发送消息到那台Broker，改成发到其他Broker上去。

其次，假设你必须要发送消息给那台Broker，那么他挂了，他的Slave机器是一个备份，可以继续使用，可以考虑等一会儿去跟他的Slave进行通信。

总之，这些都是思路，但是现在我们先知道，对于生产者而言，他是有一套容错机制的，即使一下子没感知到某个Broker挂了，他可以有别的方案去应对。而且过一会儿，系统又会重新从NameServer拉取最新的路由信息了，此时就会知道有一个Broker已经宕机了。

RocketMQ的Master-Slave模式采取的是Slave Broker不停的发送请求到Master Broker去拉取消息。Pull模式拉取消息

Master Broker主要是接收系统的消息写入，然后会同步给Slave Broker，那么其实本质上Slave Broker也应该有一份一样的数据。而系统在获取消息的时候， 有可能从Master Broker获取消息，也有可能从Slave Broker获取消息 。

Slave Broke挂掉有一点影响，但是影响不太大

因为消息写入全部是发送到Master Broker的，然后消息获取也可以走Master Broker，只不过有一些消息获取可能是从Slave Broker去走的。所以如果Slave Broker挂了，那么此时无论消息写入还是消息拉取，还是可以继续从Master Broke去走，对整体运行不影响。

只不过少了Slave Broker，会导致所有读写压力都集中在Master Broker上。

Master Broker挂掉 对消息的写入和获取都有一定的影响了。但是其实本质上而言，Slave Broker也是跟Master Broker一样有一份数据在的，只不过Slave Broker上的数据可能有部分没来得及从Master Broker同步。

在RocketMQ的实现中，采用的是TCP长连接进行通信。

也就是说，Broker会跟每个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去

MQ中的核心数据模型Topic，表达的意思就是一个数据集合的意思。我们可以在创建Topic的时候指定让他里面的数据分散存储在多台Broker机器上，比如一个Topic里有1000万条数据，此时有2台Broker，那么就可以让每台Broker上都放500万条数据。这样就可以把一个Topic代表的数据集合分布式存储在多台机器上了。

发送消息之前需要先有一个Topic，然后在发送消息的时候指定要发送到哪个Topic。既然已经知道要发送的Topic，那么就可以跟NameServer建立一个TCP长连接，然后定时从他那里拉取到最新的路由信息，包括集群里有哪些Broker，集群里有哪些Topic，每个Topic都存储在哪些Broker上。然后生产者系统自然就可以通过路由信息找到自己要投递消息的Topic分布在哪几台Broker上，此时可以根据负载均衡算法，从里面选择一台Broke机器出来，比如round robine轮询算法，或者是hash算法。

注意 :生产者一定是投递消息到Master Broker的，然后Master Broker会同步数据给他的Slave Brokers，实现一份数据多份副本，保证Master故障的时候数据不丢失，而且可以自动把Slave切换为Master提供服务。

消费者系统其实跟生产者系统原理是类似的，他们也会跟NameServer建立长连接，然后拉取路由信息，接着找到自己要获取消息的Topic在哪几台Broker上，就可以跟Broker建立长连接，从里面拉取消息

起因：在实际项目开发过程中，需要使用RabbitMQ来实现消息队列的功能，但仅仅实现功能之后并不能对自己满足，既然学一次，就要更深的了解她，吃一吃架构方面的相关内容，提升自己。

RabbitMQ在镜像集群中，机器其实是平行关系，所有的节点都是互相复制的

场景描述：

A是Master

B是Slave

A正常运行，B宕机了，只需要启动B即可，B就会自动加入集群

A和B都宕机了，只要A在B之前启动就可以了

A和B都宕机了，A启动不起来了，即便是B启动了，有可以B直接启动不了啦

B和C都加入了A为Master的集群，这个时候都需要将B和C从A的集群中forget，B和C启动不起来了

RabbitMQv32版本以后提供了一个离线清除集群节点的命令参数，也就是节点无法启动状态下

HAProxy是一款提供高可用的负载均衡器（之前大家都是使用的Nginx居多，upstream反向代理实现负载均衡非常容易），HAProxy可以基于TCP四层（Lvs也是TCP四层的），HTTP七层（Nginx是HTTP七层）的负载均衡应用代理软件，免费高速可靠的一种LBS解决方案

HAProxy的并发连接完全可以支持以万为单位的

Nginx

优点：

1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。

2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。

3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。

4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量。

5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。

6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。可作为静态网页和服务器，在高流量环境中稳定性也很好。

7、可作为中层反向代理使用。

缺点：

1、适应范围较小，仅能支持http、https、Email协议。

2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测

3、负载均衡策略比较少：轮询、权重、IP_hash、url_hash

HAProxy

优点：

1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段)

2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。

3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡。

5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种

缺点：

1、不支持POP/SMTP协议

2、不支持SPDY协议

3、不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。

4、重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。

5、多进程模式支持不够好

HAProxy+Keepalived（负载均衡节点的高可用）

将上面的配置文件内容放入 /etc/haproxy/haproxycfg中

启动HAProxy

启用成功后可以到控制台进行验证

通过federation的配置来进行数据通道搭建

这个时候你需要自己定义一个上游节点upstream(166节点)，一个下游节点downstream(167节点)，federation是单向发送的，相当于消息发送到upstream的一个exchange上，然后转发到downstream的queue上

1、 在下游节点创建一个exchage和一个queue和binding的routingkey，用来进行数据接收

2、 在下游节点建立federation upstream规则和上游节点进行数据同步

3、 进入下游节点的federation status没有任何数据，需要建立策略来保证通道连通

4、 进入下游节点的Policy菜单，Pattern是个正则表达式，这里表示以down开头的exchange和queue都匹配

5、 这个时候看exchange和queue，规则就应用上了

6、 这个时候去federation status看，发现上游连接已经连接上了

7、 这个时候我们先去看上游的overview

8、 再看上游的exchange和queue就已经根据下游配置的upstream和policy规则将exchange和queue创建好了

灰色的这个重定向exchange不能发送消息，如果要发送则在down-exchange上进行发送

9、 我们在上游的down-exchange发送一条消息，进行测试

可以在下游查看这条消息

10、 因为上游及节点只是一个中转，如果上游及诶单也要消息down-exchange里的消息怎么办？

只需要在本地建立一个binding关系就好

不要以为每天把功能完成了就行了，这种思想是要不得的，互勉~！

第一部分： 实时调度算法介绍

对于什么是实时系统，POSIX 1003b作了这样的定义：指系统能够在限定的响应时间内提供所需水平的服务。而一个由Donald Gillies提出的更加为大家接受的定义是：一个实时系统是指计算的正确性不仅取决于程序的逻辑正确性，也取决于结果产生的时间，如果系统的时间约束条件得不到满足，将会发生系统出错。

实时系统根据其对于实时性要求的不同，可以分为软实时和硬实时两种类型。硬实时系统指系统要有确保的最坏情况下的服务时间，即对于事件的响应时间的截止期限是无论如何都必须得到满足。比如航天中的宇宙飞船的控制等就是现实中这样的系统。其他的所有有实时特性的系统都可以称之为软实时系统。如果明确地来说，软实时系统就是那些从统计的角度来说，一个任务（在下面的论述中，我们将对任务和进程不作区分）能够得到有确保的处理时间，到达系统的事件也能够在截止期限到来之前得到处理，但违反截止期限并不会带来致命的错误，像实时多媒体系统就是一种软实时系统。

一个计算机系统为了提供对于实时性的支持，它的操作系统必须对于CPU和其他资源进行有效的调度和管理。在多任务实时系统中，资源的调度和管理更加复杂。本文下面将先从分类的角度对各种实时任务调度算法进行讨论，然后研究普通的 Linux操作系统的进程调度以及各种实时Linux系统为了支持实时特性对普通Linux系统所做的改进。最后分析了将Linux操作系统应用于实时领域中时所出现的一些问题，并总结了各种实时Linux是如何解决这些问题的。

1 实时CPU调度算法分类

各种实时操作系统的实时调度算法可以分为如下三种类别[Wang99][Gopalan01]：基于优先级的调度算法（Priority-driven scheduling-PD）、基于CPU使用比例的共享式的调度算法（Share-driven scheduling-SD）、以及基于时间的进程调度算法（Time-driven scheduling-TD），下面对这三种调度算法逐一进行介绍。

11 基于优先级的调度算法

基于优先级的调度算法给每个进程分配一个优先级，在每次进程调度时，调度器总是调度那个具有最高优先级的任务来执行。根据不同的优先级分配方法，基于优先级的调度算法可以分为如下两种类型[Krishna01][Wang99]：

静态优先级调度算法：

这种调度算法给那些系统中得到运行的所有进程都静态地分配一个优先级。静态优先级的分配可以根据应用的属性来进行，比如任务的周期，用户优先级，或者其它的预先确定的策略。RM（Rate-Monotonic）调度算法是一种典型的静态优先级调度算法，它根据任务的执行周期的长短来决定调度优先级，那些具有小的执行周期的任务具有较高的优先级。

动态优先级调度算法：

这种调度算法根据任务的资源需求来动态地分配任务的优先级，其目的就是在资源分配和调度时有更大的灵活性。非实时系统中就有很多这种调度算法，比如短作业优先的调度算法。在实时调度算法中， EDF算法是使用最多的一种动态优先级调度算法，该算法给就绪队列中的各个任务根据它们的截止期限（Deadline）来分配优先级，具有最近的截止期限的任务具有最高的优先级。

12 基于比例共享调度算法

虽然基于优先级的调度算法简单而有效，但这种调度算法提供的是一种硬实时的调度，在很多情况下并不适合使用这种调度算法：比如象实时多媒体会议系统这样的软实时应用。对于这种软实时应用，使用一种比例共享式的资源调度算法（SD算法）更为适合。

比例共享调度算法指基于CPU使用比例的共享式的调度算法，其基本思想就是按照一定的权重（比例）对一组需要调度的任务进行调度，让它们的执行时间与它们的权重完全成正比。

我们可以通过两种方法来实现比例共享调度算法[Nieh01]：第一种方法是调节各个就绪进程出现在调度队列队首的频率，并调度队首的进程执行；第二种做法就是逐次调度就绪队列中的各个进程投入运行，但根据分配的权重调节分配个每个进程的运行时间片。

比例共享调度算法可以分为以下几个类别：轮转法、公平共享、公平队列、**调度法（Lottery）等。

比例共享调度算法的一个问题就是它没有定义任何优先级的概念；所有的任务都根据它们申请的比例共享CPU资源，当系统处于过载状态时，所有的任务的执行都会按比例地变慢。所以为了保证系统中实时进程能够获得一定的CPU处理时间，一般采用一种动态调节进程权重的方法。

13 基于时间的进程调度算法

对于那些具有稳定、已知输入的简单系统，可以使用时间驱动（Time-driven:TD）的调度算法，它能够为数据处理提供很好的预测性。这种调度算法本质上是一种设计时就确定下来的离线的静态调度方法。在系统的设计阶段，在明确系统中所有的处理情况下，对于各个任务的开始、切换、以及结束时间等就事先做出明确的安排和设计。这种调度算法适合于那些很小的嵌入式系统、自控系统、传感器等应用环境。

这种调度算法的优点是任务的执行有很好的可预测性，但最大的缺点是缺乏灵活性，并且会出现有任务需要被执行而CPU却保持空闲的情况。

2 通用Linux系统中的CPU调度

通用Linux系统支持实时和非实时两种进程，实时进程相对于普通进程具有绝对的优先级。对应地，实时进程采用SCHED_FIFO或者SCHED_RR调度策略，普通的进程采用SCHED_OTHER调度策略。

在调度算法的实现上，Linux中的每个任务有四个与调度相关的参数，它们是rt_priority、policy、priority（nice）、counter。调度程序根据这四个参数进行进程调度。

在SCHED_OTHER 调度策略中，调度器总是选择那个priority+counter值最大的进程来调度执行。从逻辑上分析，SCHED_OTHER调度策略存在着调度周期（epoch），在每一个调度周期中，一个进程的priority和counter值的大小影响了当前时刻应该调度哪一个进程来执行，其中 priority是一个固定不变的值，在进程创建时就已经确定，它代表了该进程的优先级，也代表这该进程在每一个调度周期中能够得到的时间片的多少； counter是一个动态变化的值，它反映了一个进程在当前的调度周期中还剩下的时间片。在每一个调度周期的开始，priority的值被赋给 counter，然后每次该进程被调度执行时，counter值都减少。当counter值为零时，该进程用完自己在本调度周期中的时间片，不再参与本调度周期的进程调度。当所有进程的时间片都用完时，一个调度周期结束，然后周而复始。另外可以看出Linux系统中的调度周期不是静态的，它是一个动态变化的量，比如处于可运行状态的进程的多少和它们priority值都可以影响一个epoch的长短。值得注意的一点是，在24以上的内核中， priority被nice所取代，但二者作用类似。

可见SCHED_OTHER调度策略本质上是一种比例共享的调度策略，它的这种设计方法能够保证进程调度时的公平性--一个低优先级的进程在每一个epoch中也会得到自己应得的那些CPU执行时间，另外它也提供了不同进程的优先级区分，具有高priority值的进程能够获得更多的执行时间。

对于实时进程来说，它们使用的是基于实时优先级rt_priority的优先级调度策略，但根据不同的调度策略，同一实时优先级的进程之间的调度方法有所不同：

SCHED_FIFO：不同的进程根据静态优先级进行排队，然后在同一优先级的队列中，谁先准备好运行就先调度谁，并且正在运行的进程不会被终止直到以下情况发生：1被有更高优先级的进程所强占CPU；2自己因为资源请求而阻塞；3自己主动放弃CPU（调用sched_yield）；

SCHED_RR：这种调度策略跟上面的SCHED_FIFO一模一样，除了它给每个进程分配一个时间片，时间片到了正在执行的进程就放弃执行；时间片的长度可以通过sched_rr_get_interval调用得到；

由于Linux系统本身是一个面向桌面的系统，所以将它应用于实时应用中时存在如下的一些问题：

Linux系统中的调度单位为10ms，所以它不能够提供精确的定时；

当一个进程调用系统调用进入内核态运行时，它是不可被抢占的；

Linux内核实现中使用了大量的封中断操作会造成中断的丢失；

由于使用虚拟内存技术，当发生页出错时，需要从硬盘中读取交换数据，但硬盘读写由于存储位置的随机性会导致随机的读写时间，这在某些情况下会影响一些实时任务的截止期限；

虽然Linux进程调度也支持实时优先级，但缺乏有效的实时任务的调度机制和调度算法；它的网络子系统的协议处理和其它设备的中断处理都没有与它对应的进程的调度关联起来，并且它们自身也没有明确的调度机制；

3 各种实时Linux系统

31 RT-Linux和RTAI

RT -Linux是新墨西哥科技大学（New Mexico Institute of Technology）的研究成果[RTLinuxWeb][Barabanov97]。它的基本思想是，为了在Linux系统中提供对于硬实时的支持，它实现了一个微内核的小的实时操作系统（我们也称之为RT-Linux的实时子系统），而将普通Linux系统作为一个该操作系统中的一个低优先级的任务来运行。另外普通Linux系统中的任务可以通过FIFO和实时任务进行通信。RT-Linux的框架如图 1所示：

图 1 RT-Linux结构

RT -Linux的关键技术是通过软件来模拟硬件的中断控制器。当Linux系统要封锁CPU的中断时时，RT-Linux中的实时子系统会截取到这个请求，把它记录下来，而实际上并不真正封锁硬件中断，这样就避免了由于封中断所造成的系统在一段时间没有响应的情况，从而提高了实时性。当有硬件中断到来时， RT-Linux截取该中断，并判断是否有实时子系统中的中断例程来处理还是传递给普通的Linux内核进行处理。另外，普通Linux系统中的最小定时精度由系统中的实时时钟的频率决定，一般Linux系统将该时钟设置为每秒来100个时钟中断，所以Linux系统中一般的定时精度为 10ms，即时钟周期是10ms，而RT-Linux通过将系统的实时时钟设置为单次触发状态，可以提供十几个微秒级的调度粒度。

RT-Linux实时子系统中的任务调度可以采用RM、EDF等优先级驱动的算法，也可以采用其他调度算法。

RT -Linux对于那些在重负荷下工作的专有系统来说，确实是一个不错的选择，但他仅仅提供了对于CPU资源的调度；并且实时系统和普通Linux系统关系不是十分密切，这样的话，开发人员不能充分利用Linux系统中已经实现的功能，如协议栈等。所以RT-Linux适合与工业控制等实时任务功能简单，并且有硬实时要求的环境中，但如果要应用与多媒体处理中还需要做大量的工作。

意大利的RTAI( Real-Time Application Interface )源于RT-Linux，它在设计思想上和RT-Linux完全相同。它当初设计目的是为了解决RT-Linux难于在不同Linux版本之间难于移植的问题，为此，RTAI在 Linux 上定义了一个实时硬件抽象层，实时任务通过这个抽象层提供的接口和Linux系统进行交互，这样在给Linux内核中增加实时支持时可以尽可能少地修改 Linux的内核源代码。

32 Kurt-Linux

Kurt -Linux由Kansas大学开发，它可以提供微秒级的实时精度[KurtWeb] [Srinivasan]。不同于RT-Linux单独实现一个实时内核的做法，Kurt -Linux是在通用Linux系统的基础上实现的，它也是第一个可以使用普通Linux系统调用的基于Linux的实时系统。

Kurt-Linux将系统分为三种状态：正常态、实时态和混合态，在正常态时它采用普通的Linux的调度策略，在实时态只运行实时任务，在混合态实时和非实时任务都可以执行；实时态可以用于对于实时性要求比较严格的情况。

为了提高Linux系统的实时特性，必须提高系统所支持的时钟精度。但如果仅仅简单地提高时钟频率，会引起调度负载的增加，从而严重降低系统的性能。为了解决这个矛盾， Kurt-Linux采用UTIME所使用的提高Linux系统中的时钟精度的方法[UTIMEWeb]：它将时钟芯片设置为单次触发状态（One shot mode），即每次给时钟芯片设置一个超时时间，然后到该超时事件发生时在时钟中断处理程序中再次根据需要给时钟芯片设置一个超时时间。它的基本思想是一个精确的定时意味着我们需要时钟中断在我们需要的一个比较精确的时间发生，但并非一定需要系统时钟频率达到此精度。它利用CPU的时钟计数器TSC (Time Stamp Counter)来提供精度可达CPU主频的时间精度。

对于实时任务的调度，Kurt-Linux采用基于时间（TD）的静态的实时CPU调度算法。实时任务在设计阶段就需要明确地说明它们实时事件要发生的时间。这种调度算法对于那些循环执行的任务能够取得较好的调度效果。

Kurt -Linux相对于RT-Linux的一个优点就是可以使用Linux系统自身的系统调用，它本来被设计用于提供对硬实时的支持，但由于它在实现上只是简单的将Linux调度器用一个简单的时间驱动的调度器所取代，所以它的实时进程的调度很容易受到其它非实时任务的影响，从而在有的情况下会发生实时任务的截止期限不能满足的情况，所以也被称作严格实时系统（Firm Real-time）。目前基于Kurt-Linux的应用有：ARTS（ATM Reference Traffic System）、多媒体播放软件等。另外Kurt-Linux所采用的这种方法需要频繁地对时钟芯片进行编程设置。

33 RED-Linux

RED -Linux是加州大学Irvine分校开发的实时Linux系统[REDWeb][ Wang99]，它将对实时调度的支持和Linux很好地实现在同一个操作系统内核中。它同时支持三种类型的调度算法，即：Time-Driven、 Priority-Dirven、Share-Driven。

为了提高系统的调度粒度，RED-Linux从RT-Linux那儿借鉴了软件模拟中断管理器的机制，并且提高了时钟中断频率。当有硬件中断到来时，RED-Linux的中断模拟程序仅仅是简单地将到来的中断放到一个队列中进行排队，并不执行真正的中断处理程序。

另外为了解决Linux进程在内核态不能被抢占的问题， RED-Linux在Linux内核的很多函数中插入了抢占点原语，使得进程在内核态时，也可以在一定程度上被抢占。通过这种方法提高了内核的实时特性。

RED-Linux的设计目标就是提供一个可以支持各种调度算法的通用的调度框架，该系统给每个任务增加了如下几项属性，并将它们作为进程调度的依据：

Priority：作业的优先级；

Start-Time：作业的开始时间；

Finish-Time：作业的结束时间；

Budget：作业在运行期间所要使用的资源的多少；

通过调整这些属性的取值及调度程序按照什么样的优先顺序来使用这些属性值，几乎可以实现所有的调度算法。这样的话，可以将三种不同的调度算法无缝、统一地结合到了一起。