（接上篇《The Part-Time Parliament》译文（中））
3. 多法令议会
多法令议会初建时，满足一致性和进展需求的协议从上述单法令协议派生出。3.1和3.2节描述了原始多法令议会协议的产生以及属性。3.3节讨论了协议的进一步发展。
3.1 多法令议会协议
除了只通过一条法令，Paxos议会还需通过一系列有序法令。和在单法令会议协议中一样，需要选举一个领导者。任何人想要通过法令，需要通知领导者，领导者给法令分配一个编号并且尝试通过该法令。逻辑上，多法令议会协议为每个法令执行一次单独的完整的单法令会议协议的实例。然而，单个总统被选择以完成所有这些实例，故协议的前两步总统只需执行一次。
派生多法令议会协议的关键在于，在单法令会议协议中观察到，总统一直到第3步才选择法令或者法定人数。一个新选举的总统p给某个议员集合发送一条消息，这条消息作为多法令议会协议所有实例的NextBallot(ba)消息。（有无数个实例——每个法令一个实例。）议员q回复单个信息作为多法令议会协议所有实例第(2)步的LastVote消息。这个消息只包括有限数量的信息，因为q只在有限个实例中进行了投票。
当新总统从一个大多数集合中的每个成员那收到了回复，他就准备为多法令议会协议的每个实例执行步骤(3)。对于某些有限数量的实例，第(3)步中法令的选择将由B3决定。对于这些实例，总统立即执行步骤(3)来通过这些法令。那么，无论总统什么时候收到想要通过法令的请求，他会选择能自由选择的最小编号的法令，并且执行步骤(3)以尝试通过这个法令。
对这个简单协议进行下列修改就变成了Paxos多法令议会协议：
——对于已经知道结果的法令号码，不需要执行协议。因此，如果一个新选举的总统p在他的分类账中写有号码小于等于n的所有法令，那么他会发送一个NextBallot(ba, n)消息作为多法令议会协议中法令号码大于n的所有实例的NextBallot(ba)消息。议员q对这条消息进行响应，通知p所有编号大于n并且已经出现在q分类账中的法令（此外对于不在q分类账中的法令还发送通常的LastVote信息），并且q请求p发送不在他分类账中编号小于等于n的法令。
——假定法令125和126在上周五下午被提出，法令126成功通过并且被写在一个或者两个分类账中，但是在其他事情发生之前，议员们都回家过周末了。假定接下来的周一∆φωρκ被选举为新总统并且知道了法令126，但是她不知道法令125，因为之前的总统以及为法令125投过票的所有议员都离开了议会厅。她将会举行一次投票来通过法令126，这么一来，分类账上将会有一个125的缺口。给一个新的法令分配125编号将会使该法令在法令126之前，而法令126是在上星期通过的。以这种方式乱序地通过法令可能会造成混淆——例如，提出新法令的市民之所以提出新法令是因为他知道法令126已经通过。所以，∆φωρκ会尝试通过一个传统的法令，该法令不会对Paxos岛上的任何人造成影响：
125：二月份是全国橄榄日
通常，一个新的总统会以通过“橄榄日”法令的方式填充他分类账上的空白。
多法令议会协议的一致性和进展属性从单法令会议协议的对应属性派生而来。根据我们的了解，Paxos居民没有纪录多法令议会协议的精确描述，因为多法令议会协议只是单法令会议协议简单的派生。
3.2 多法令议会协议的属性
3.2.1 法令的顺序
多个不同法令的投票可能并发发生，投票由不同的议员发起——每个议员在发起投票时，都认为自己是总统。我们不能准确地说出法令会以什么顺序被通过，特别是在不知道总统是怎么选举的情况下。然而，我们可以推导出关于法令顺序的一个很重要的属性。
我们说法令被提出，是总统在步骤3中选择该法令作为会议协议的对应实例。我们说法令通过，是当它被第一次写在分类账上。在总统提出任何法令之前，他必须从一个大多数集合中的每个成员那获取他们进行过的选票的信息。已经通过的任何法令一定被这个大多数集合中至少一个议员投过选票。因此，总统在发起新投票之前一定已经知道所有之前通过的法令。总统不会用重要的法令（也就是除了“橄榄日”法令以外的任何法令）来填充分类账中的空白。他也不会乱序地提出法令。因此，协议满足下列法令顺序属性：
如果法令A和B是重要的法令并且法令A在法令B被提出之前已经通过了，那么法令A比法令B有一个更小的法令号码。
3.2.2 如果没有人进入或离开议会厅
尽管我们不知道具体选举新总统的细节，但是当总统被选举之后，并且没有人进入或者离开会议厅时，我们知道议会是如何工作的。在收到一个通想要过法令的请求之后——或者直接从市民那收到或者从另一个议员那收到——总统会分配给法令一个编号并且通过以下信息交换来通过它：（编号是指会议协议中相应的步骤）
(3)总统给法定人数中的每个议员发送一个BeginBallot信息。
(4)法定人数中的每个议员给总统发送Voted信息。
(5)总统给每个议员发送Success信息。
假定一个议会有N个议员和大约N/2的法定人数的话，这总共有三个消息延迟，大概有3N个消息。此外，如果议会很忙的话，总统会将一个法令的BeginBallot消息和上一个法令的Success消息一起发送，这样每个法令只有大概2N个消息。
3.3 进一步发展
管理小岛比Paxos居民认为的要更加复杂。一些问题出现了，他们需要对协议做出改变。一些最重要的改变如下所述。
3.3.1 选举新总统
首先用之前所提方法（只基于姓名的字母表顺序）来选择议会的总统。因此，当议员Ωκι从长达6个月的度假中回来的时候，他被立即任命为总统——即使他不知道在他缺席期间发生了什么。议会活动停止了，而Ωκι，纪录地很慢，努力地复制6个月的法令，使他的分类账最新。
这次事故引起了一场关于最好的选择总统方法的辩论。一些Paxos居民认为一旦一个议员成为了总统，他将一直是总统，直到他离开议会厅。一组有影响力的公民想要议会厅里最富有的议员成为总统，因为他能雇佣更多的法学家以及仆人来帮助他履行总统的职责。他们争论，一旦一个富有的议员保证他的分类账是最新的，就没有理由不让他担任总统。然而，其他人，认为最正直的公民应该成为总统，不管财富的多少。正直意味着不太可能是不诚实的，尽管没有Paxos居民在大庭广众下承认官员渎职的可能性。不幸的是，这场辩论的结果并不知道，没有最终使用的总统选举协议的记录。
3.3.2 厚的分类帐
随着时间的流逝，议会通过了越来越多的法令。Paxos居民不得不翻阅一长串法令来寻找目前的橄榄税或者什么颜色的山羊可以售卖。在一次长期的航程之后返回议会厅的议员必须复制很多内容使自己的分类账保持最新。最终，议员被迫将他们的分类账从法令清单转化为法律书籍，法律书籍只包含法律当前状态以及在该状态下通过的最后一条法令的编号。
为了知道当前的橄榄税，人们在法律书中查找“税收”；为了知道什么颜色的山羊可以售卖，人们在法律书中查找“商业法律”。如果一个议员的分类账包含法令1298的法律，并且他知道法令1299将橄榄税设置为每吨6德拉马克，他只会改变橄榄税法律的条目，并且记下他的法令已经到了1299。如果他接下来知道法令1302，他会将法令1302写在分类账的后面，并且一直等待，直到他知道法令1300和1301，之后，将会把法令1302合并进法律书。
为了让短时间离开的议员在不复制整本法律书的情况下追赶上进度，议员在书的背面记下过去一周的法令清单。他们可能将清单记在一张纸上，但是对于议员来说，将通过的法令记在分类账上，并且一周更新法律书2~3次是很方便的。
3.3.3 官僚体系
随着Paxos日益兴旺，议员也越来越忙。议会不能够处理政府的所有细节，所以设立了官僚体系。议会通过一条法令来任命一个奶酪检察院来做决定，而不是通过一个法令来宣布是否每一批奶酪都可以销售。
很快发现选举官僚并不像一开始以为的那样简单。议会通过了一条法令，任命∆˘ικστρα是第一个奶酪监管员。在几个月之后，商人抱怨∆˘ικστρα太严格了，拒绝了很好的奶酪。议会接着通过了法令来替代他：
1375：Γωυδα是新的奶酪监管员。
但是∆˘ικστρα并没有密切关注议会的决定，所以他没有马上知道这条法令。奶酪市场有一段时间的混乱，因为∆˘ικστρα和Γωυδα都检查奶酪并且做出了冲突的决定。
为了防止这样的混乱，Paxos居民必须保证一个位置在任何时间最多只有一位官员。为了实现这个保证，总统提出法令时将日期以及时间作为法令的一部分。一个任命∆˘ικστρα为奶酪监管员的法令为：
2716: 72年1月15日8:30——∆˘ικστρα担任3个月的奶酪监管员
这条法令说明了∆˘ικστρα的任职期或者是从1月15号8:30开始，或者是在之前的监管员任职期限到了之后——以较晚者为准。他的任职期将在4月15号8:30结束，除非他要求总统通过一条这样的法令来辞职：
2834: 72年4月3号9:15——∆˘ικστρα作为奶酪监管员辞职
一个官员被短期任命，所以它可以快速被替换——例如，如果他离开小岛的话。如果官员的工作令人满意的话，议会将会通过一条法令来延伸官员的任期。
时间用来确定官僚们目前是否担任职务。Paxos居民并不知道机械时钟，但是Paxos居民能通过太阳或者星星的位置来判断时间，精度在15分钟之内。如果∆˘ικστρα的任期在8:30开始，他将会在他观察到8:45的时候才开始监管奶酪。
如果较高编号的法令总是有较迟的提议时间，这种任命官员的方法很容易起作用。但是，如果议会通过下列法令：
2854：78年4月9号9:45——ΦρανσΦζ担任2个月的红酒品尝师
2855：78年4月9号9:20——ΠνυΦλ˘ι担任1个月的红酒品尝师
这两条法令是在9:30-9:35期间由不同的议员（都认为他们自己是总统）提出。这样无序的提议时间很容易被避免，因为议会协议满足下列属性：
如果两个法令由不同的总统通过，那么一个总统在得知另一个法令已经被提出之后才提出他自己的法令。
为了证明满足这个属性，假定法令D在投票编号为ba的投票中成功通过，法令D’在投票编号为ba’的投票中成功通过，并且ba<ba’。q为在这两次投票中进行过投票的议员。D’的投票以NextBallot(ba’, n)消息开始。如果消息的发送者还不知道D，那么n要小于D的法令号码，那么q对于NextBallot消息的回复一定包含他已经投票给D的信息。
3.3.4 学习法律
除了请求通过法令，普通的居民需要查询小岛上最近的法律。Paxos协议首先考虑居民可以查阅任何议员的分类账，但是下列事件表明，需要一个更复杂的方法。几个世纪以来，只卖白山羊是合法的。名为∆ωλΦφ的农民让议会通过法令：
77：允许售卖黑山羊
∆ωλΦφ接着让他的牧羊人将一些黑山羊卖给名为ΣκΦΦν的商人。作为一名遵守法律的市民，ΣκΦΦν询问议员ΣτωκµΦ˘ιρ这样的买卖是否合法。但是ΣτωκµΦ˘ιρ已经离开了议会厅，并且在他的分类账上法令76之后就没有条目了。他建议ΣκΦΦν这次买卖在当前法律下是不合法的，所以ΣκΦΦν拒绝购买这些山羊。
这一事件导致下列关于法律查询的单调性条件的形成：
如果一次查询先于第二次查询，那么第二次查询不能获得比第一次查询更早的法律状态。
如果一个居民得知一个特定的法令已经通过，那么获取这个法令的过程就是这个单调性条件适用的隐式的查询。单调性条件的解释随着时间而发生变化。
一开始，通过为每次查询通过一个法令来实现单调性。如果Σ∂ν˘ιδΦρ想要知道当前橄榄税，他将会使议会通过一条如下的法令：
87：居民Σ∂ν˘ιδΦρ正在读法律
他将会查询任何至少通过了法令86的分类账来了解橄榄税。如果居民ΓρΦΦς接着再查询橄榄税，他的查询的法令是在法令87通过之后提出的，所以根据法令顺序属性他会收到一个比87更大法令号码。因此ΓρΦΦς不会比Σ∂ν˘ιδΦρ获得一个更早的橄榄税的值。这种查询法律的方法满足单调性条件，这里，“先于”被理解为，当且仅当A完成在B开始之前，才能说查询A“先于”查询B。
很快发现为每个查询通过一条法令很麻烦。Paxos居民意识到如果他们通过改变“先于”的语义来减弱单调性规则，会有一个更简单的方法。他们决定对于一件先于另一件的事，第一件事不止要在更早的时间发生，而且他必须要在因果关系上对第二件事有影响。更弱的单调性条件防止了农民∆ωλΦφ和商人ΣκΦΦν遇见的问题，因为在∆ωλΦφ隐式的查询结束和ΣκΦΦν开始查询之间有一个事件的因果链。
更弱的单调性条件通过在所有的商业交易和查询中使用法令号码来满足。例如，农民∆ωλΦφ，拥有许多不是白的山羊，让议会通过法令：
277：棕山羊的买卖是被允许的
当将他的棕山羊卖给ΣκΦΦν的时候，他通知商人，这次买卖因为法令277是合法的。ΣκΦΦν接着询问议员ΣτωκµΦ˘ιρ根据至少通过了法令277的法律来看，这次买卖是否是合法的。如果ΣτωκµΦ˘ιρ的分类账上没有完成法令277，他会等待通过法令277或者通知ΣκΦΦν去问其他人。如果ΣτωκµΦ˘ιρ的分类账上通过了法令298，那么他会告诉ΣκΦΦν根据法令编号298，这次买卖是合法的。商人ΣκΦΦν将会记住法令298为了在他下一次商业交易或者法律查询中使用。
Paxos协议已经满足了单调性条件。但是普通的市民不喜欢记法令号码。再一次地，Paxos居民通过重新解读单调性条件来解决这个问题——这一次，通过改变法律状态的含义。他们将法律分为不同的领域，每个领域选择一个议员作为专家。法律的每个领域的当前状态由专家的分类账决定。例如，假定法令1517改变了关税并且法令1518改变了税收法律。如果税收法律的专家在关税法律的专家知道其中一个法令之前知道了这两个法令，税收法律将会首先改变，产生了一种以数字顺序制定法律所不能得到的法律顺序。
为了避免当前状态的冲突的定义，Paxos协议需要在任何领域一次最多只能有一位专家。这个需求通过使用和选官僚（3.3.3）相同的方法来选择专家来实现。如果每次查询只包括法律的单个区域，单调性通过将查询转向领域的专家来实现，领域的专家根据分类账上的内容进行回答。既然知道一条通过的法令会构成一次隐含查询的结果，Paxos协议要求一条法令最多只能改变法律的一个领域，并且法令通过的通知只能来自于这个领域的专家。
包含多个领域的查询不难解决。当商人Λισκωφ询问是否进口金色羊毛的关税比本地购买的销售税要高，关税和税收专家必须合作来提供答案。例如，税收专家可以通过首先询问关税专家进口羊毛的关税，然后回答Λισκωφ，只要他在收到回复之前不改变他的分类账。
在需同时对法律的若干领域进行彻底改变之前，这种方法是令人满意的。接着，Paxos居民意识到维持一致性的必要需求不是一条法令只影响一个领域，而是法令影响的每个领域有相同的专家。议会通过任命单个议员为所有这些领域的专家，实现用单条法令来改变法律的几个领域。此外，只要法律的领域不改变，相同的领域可以有多个专家。在所得税到期之前，议会将任命多个税法专家来处理关于税法的大量询问。
3.3.5 不诚实的议员以及诚实的错误
尽管官方声称所有议员都是诚实的，但是在Paxos历史上，一定有一些不诚实的议员。当这些不诚实的议员被抓住，他们就会被放逐。通过发送矛盾的信息，一名恶意的议员可能会导致不同议员的分类账不一致。不一致也有可能由诚实议员或者信使一段时间的失忆导致。
当意识到不一致性，可以通过法令很容易地纠正。例如，关于当前橄榄税的不一致性可以通过让议会通过一条新法令来规定税值来消除。困难在于在没有人意识到不一致性的时候纠正不一致的分类账。
议员不诚实或者错误的存在可以从议会建立几年后开始在分类账中出现的冗余法令推断出来。例如，即使法令2155已经将橄榄税设置为每吨9德拉马克，并且没有干预的法令改变它，下列法令依然通过了：
2605：橄榄税为每吨9德拉马克
议会似乎每六个月循环它的法律，以便于即使议员的分类账一开始不一致，所有的议员将会在六个月之内就当前法律达成一致。大家相信，通过这些冗余法令的使用，Paxos协议使他们的议会自我稳定。（自我稳定是现代词汇，由Dijkstra提出）。
并不十分清楚在一个议员随意进出的议会，自我稳定意味着什么。Paxos居民不会乐意在一致性得到保证之前，需要所有的议员同时在议会厅里。然而，实现一致性要求如果一个议员在他的分类账中有一个特定法令号码的条目并且另一个议员没有，那么第二个议员将最终会填上该条目。
不幸的是，我们不知道Paxos协议实现了哪种自我稳定属性或者他们是如何实现的。Paxos岛上的数学家毫无疑问解决了这个问题，但是他们的工作还没有被发现。我希望将来的考古学家去Paxos小岛上考察的时候，将会优先搜索关于自我稳定的手稿。
3.3.6 选择新议员
首先，议会的成员资格是遗传的，由父母传给孩子。当较老的政治家Παρνας 退休，他将他的分类账传给他的孩子，进行不中断的纪录。这不对和Παρνας交流的议员产生影响。
随着之前的家族移民，新的家族搬入，系统必须进行改变。Paxos协议决定通过法令进行议会成员的加入和移除。这造成了循环问题：议会的成员资格由通过的法令决定，但是通过法令需要知道一个大多数集合有哪些人，这将取决于谁是议会的成员。可以通过由法令n-3指定通过法令n使用的议会的成员资格来打破这个循环。直到总统知道法令3252之前的所有法令，他才尝试通过法令3255。在实际中，在通过下列法令之后：
3252：Στρωνγ现在是一个议员
总统将立即通过法令3253和法令3254，他们都是“橄榄日”法令。
以这种方式改变议会的组成是很危险的，一定要小心。一致性和进展条件将总会保持，然而，只有在大多数牧师在会议厅内，进展条件才可确保进展。当大多数牧师曾经在会议厅内，并不能确保进展。事实上，选择议员的机制导致了议会系统在Paxos的倒台。因为一个法学家的错误，一条应该褒奖在沉船中淹死的水手的法令变成了任命他们为议会的成员。这条法令的通过阻止了任何新法令的通过——包括为了纠正这个法令提出的法令。Paxos的政府停止运行。一个名为Λαµπσων的将军利用这个混乱发动了政变，建立了军事专政政府，结束了几个世纪以来进步的政府。Paxos在一系列腐败的专政下越来越弱，并且不能击退来自东边的入侵，导致了它的文明的灭亡。
4. 与计算机科学的相关性
4.1 状态机方法
尽管Paxos议会已经被毁灭几个世纪了，它的协议仍然是有用的。例如，考虑一个简单的被用于域名服务器的分布式数据库系统。数据库的状态包括将值分配给名称。数据库的副本由多个服务器维持。一个客户程序能发出请求给任何服务器，一个读请求或者一个改变名称的写请求。有两种读请求：一种是慢读，将返回当前分配给某个名称的值，一种的快读，更快一点但是或许不会反映出数据库最近的改变。
在这个数据库系统和Paxos议会之间有一种明显的对应关系：
议会 分布式系统
议员 服务器
居民 客户程序
当前法律数据库状态
图2 简单数据库的状态机
客户端改变值的请求由通过一条法令来执行。一次慢读包括通过一条法令，像3.3.4描述的那样。一次快读由读取服务器当前的数据库版本来实现。Paxos议会协议提供了一种分布式，容错的数据库系统的实现。
实现分布式数据库的方法是状态机方法的一个实例，最早由Lamport在1978年提出。在这种方法中，一个人首先定义一个状态机，状态机包括一组状态集，一组命令集，一组响应集，还有一个函数，函数将响应/状态对（一对包括一个响应和一个状态）分配给每个命令/状态对。直观地，一个状态机通过产生一个响应以及改变它的状态来执行一个命令；命令和机器的当前状态决定了它的响应和它的新状态。对于分布式数据库来说，一个状态机的状态只是一个数据库状态。状态机的命令以及指定响应和新状态的函数在图2中有描述。
在状态机方法中，系统由服务器组成的网络实现。服务器将客户端请求变为状态机命令，执行命令，将状态机响应转化为对客户端的回复。一般算法确保了所有的服务器具有相同的命令序列，从而确保了他们都产生相同的响应以及状态转换序列——假定他们都从相同的起始状态开始。在数据库例子中，客户端请求执行一次慢读或者改变一个值被转化为一次状态机的读或者更新命令。这个命令被执行，状态机响应转化为对客户端的回复，通过收到客户端请求的服务器来发送客户端回复。既然所有的服务器执行相同的状态机命令序列，他们全都保持数据库版本的一致性。然而，在任何时间，某些服务器可能比另一些服务器有更早一点版本，因为一个状态机命令不需要所有的服务器在相同的时间执行。一个服务器使用他当前版本的状态去回复一次快读请求，不执行状态机命令。
系统的功能用状态机表示，状态机是从命令/状态对到响应/状态对的函数。同步和容错问题由一般算法解决，使得服务器获得相同的命令序列。当设计一个新系统时，只有状态机是新的。服务器通过一个已经被证明是正确的标准的分布式算法来获取状态机命令。函数比分布式算法更容易设计，更容易正确。
实现一个任意状态机的第一个算法在由Lamport在1978年提出。随后，设计了容忍任意固定数量（f）故障的算法[Lamport 1984]。这些算法确保了如果少于f个进程故障，那么状态机命令会在一个固定时间范围内被执行。这个算法因此适于需要即时响应的应用。但是，如果超过f个故障发生，那么不同服务器或许有状态机不一致的副本。此外，两台服务器之间不能彼此交流相当于一台服务器故障。对于一个几乎不会丢失一致性的系统来说，它必须使用f很大的算法，反过来，会在冗余的硬件，交流带宽以及响应时间上有更多的花费。
Paxos议会的协议提供了另一种方式来实现一个任意状态机。议员的法律书对应于机器状态，并且通过一条法令对应于执行一个状态机命令。得到的算法比起早期的算法没有那么强健，但花费也不大。它并不容忍任意的恶意的故障，也不能保证有界时间的响应。然而，在任意数量的（良性的）进程故障以及交流路径故障下，能保证一致性。Paxos算法适用于需要适度可靠性要求的系统，不需要为严苛的容错，即时的实现提供花费。
如果状态机由一个保证边界响应时间的算法执行，那么时间也可以是状态的一部分，机器的行为可以由时间的流逝被触发。例如，考虑一个分配资源的系统。状态可以包括客户被授予资源的时间，并且如果客户拥有资源太长时间，状态机可以自动执行命令收回所有权。
在Paxos算法中，时间不能以这种自然的方式成为状态的一部分。如果故障发生，可以花费任意长的时间去执行一条命令（通过一条法令），并且一条命令能在另一条更早提出的命令（在法令序列中出现地更早）之前被执行。然而，状态机仍可以像Paxos议会一样使用真实时间。例如，在3.3.3描述的决定谁是当前奶酪监管员的方法可以被使用去决定谁是当前资源拥有者。
4.2 提交协议
Paxos的会议协议类似于标准的三阶段提交协议。一次Paxos投票和一个三阶段提交协议都在协调者（总统）和其他的法定成员（议员）之间有5个信息交换。一个提交协议选择1-2个值——提交或中止——但会议协议选择任意的法令。要将一个提交协议转换为一个会议协议，需要在第一轮消息中发送法令。提交意味着法令通过，中止决定意味着“橄榄日”法律被通过。
会议协议与转化的提交协议不同，因为法令直到第二阶段才发送。这允许相应的会议协议对于所有的法令只执行一次第一阶段，所以通过每个法令只需要3次信息交换。
会议协议基于的理论类似于Dwork，Lynch和Stockmeyer获得的结果。然而，他们的算法在单独的轮次依次执行投票，并且似乎和会议协议无关。
自从这篇文章写出来之后，这个领域已经做了许多调查。Schneider已经调查了状态机方法。Keidar和Dolev的恢复协议[1996]以及Fekete等人的完全顺序广播算法[1997]和这里描述的Paxos协议很相似。作者也似乎不知道，Oki和Liskov[1988]的视图管理协议似乎和Paxos协议一样。
这篇文章中提到的许多修订也出现在当代或者后续的文章中。3.3.3中描述的委托方法和Gray及Cheriton提出的租约机制[1989]很像。3.3.4中Paxos使用法令号码来满足单调性条件的技术是由Ladin等人描述的[1992]。3.3.6的增加新议员的技术由Schneider提出[1990]。
网友评论