CentOS6.4+LAMP+Postfix+Dovecot+Postfixadmin+Roundcubemail (2)

大纲

十二、安装并配置病毒扫描与垃圾邮件过滤

十三、安装并配置managesieve插件

十四、常见问题分析

说明:我们继续接着上一博文继续往下面说(上一博文:http://freeloda.blog.51cto.com/2033581/1245492),首先我们来简单回忆一下我们上一篇博文的主要内容,我们说明了mail架构的主要部件,整个mail系统的工作流程,重点对比了,常规mail架构与精简mail架构的区别,重点说明了dovecot的优点,不仅能提供SASL认证,还是提供LDA功能,且效率大大的提高,不会占用太多有内存资源,然后我们具体演示了精简mail架构的配置过程,包括LAMP环境的搭建、Postfix配置、Dovecot配置、Postfixadmin配置、以及Roundcubemail的配置,完整搭建了整个邮件系统,但没有演示反垃圾邮件与邮件杀毒,在这一篇博文中我们重点讲解,反垃圾邮件与邮件杀毒,还有常见问题分析,好了下面我们就来说一说,嘿嘿!

十二、安装并配置病毒扫描与垃圾邮件过滤

1.安装安amavisd-new、clamav及spamassassin

[root@mail ~]# yum install -y  amavisd-new clamav clamav-devel clamd spamassassin

说明,amavisd-new、clamav及spamassassin可从RPMForge软件仓库安装,想想当年我们手动安装perl模块果,几十个模块一个个安装那叫一个苦B啊,嘿嘿,现在好了可以用yum直接安装,那叫一个爽!

2.查看amavisd-new、clamav及spamassassin开机自启动

[root@mail ~]# chkconfig --list | grep "amavisd\|clamd\|spamassassin"  
amavisd         0:off   1:off   2:on    3:on    4:on    5:on    6:off   
clamd           0:off   1:off   2:on    3:on    4:on    5:on    6:off   
spamassassin    0:off   1:off   2:off   3:off   4:off   5:off   6:off   
[root@mail ~]#

大家可以看到spamassassin是个服务是停止的开机没有启动,是因为amavisd-new直接将spamassassin作为一个模块使用,所以不需要守护进程,自然开机不需要启动,嘿嘿!

3.修改SpamAssassin配置文件

SpamAssassin作为amavisd-new的模块是需要特别配置,只要安装就行,但是你也可以定制它通过修改
[root@mail ~]# vim /etc/mail/spamassassin/local.cf
# These values can be overridden by editing ~/.spamassassin/user_prefs.cf   
# (see spamassassin(1) for details)
# These should be safe assumptions and allow for simple visual sifting  
# without risking lost emails.
required_hits 5  
report_safe 0   
rewrite_header Subject [SPAM]

我这里只是列出为给大家看一下,有需要的博友自行修改,我这里就不修改了!

4.修改ClamAV配置文件/etc/clamd.conf

说明,ClamAV的设定存放在/etc/clamd.conf内,我们修改/etc/clamd.conf配置文件让ClamAV知道,Amavisd-new将会利用本地的UNIX通讯端与它通信而不是利用tcp端口来与它通信!

[root@mail ~]# vim /etc/clamd.conf
#利用本地通信
LocalSocket /var/run/clamav/clamd.sock
#注释掉TCP通信端口
#TCPSocket 3310

5.修改Amavisd-new配置文件/etc/amavisd.conf

(1).通过去除以下数行的注释来停止检查病毒域垃圾邮件(由于下面数行默认是被注释掉的,因此病毒及垃圾邮件在预设中默认是被启动的)

[root@mail ~]# vim /etc/amavisd.con
# @bypass_virus_checks_maps = (1);  # controls running of anti-virus code  
# @bypass_spam_checks_maps  = (1);  # controls running of anti-spam code   
# $bypass_decode_parts = 1;         # controls running of decoders&dearchivers

(2).接着可以看到下面几行

$max_servers = 2;            # num of pre-forked children (2..30 is common), -m  
$daemon_user  = "amavis";     # (no default;  customary: vscan or amavis), -u   
$daemon_group = "amavis";     # (no default;  customary: vscan or amavis), -g   
$inet_socket_port = 10024;   # listen on this local TCP port(s)
# $notify_method  = 'smtp:[127.0.0.1]:10025';  
# $forward_method = 'smtp:[127.0.0.1]:10025';  # set to undef with milter!

说明,

$max_servers 设定同步执行的Amavisd-new进程数量,而且必须与/etc/postfix/master.cf内的amavisfeed服务的maxproc中相符合

$daemon_user及$daemon_group应该用来匹配Amavisd-new的用户及群组

$inet_socket_port   定义Amavisd-new将会在哪一个tcp端口接纳来自Postfix的连接

$notify_method及$forward_method定义Amavisd-new把邮件重新注入Postfix的途径

(3).以下是必须修改项

$mydomain = 'free.com';  #我这里是free.com域              
$MYHOME = '/var/amavis';                   
$helpers_home = "$MYHOME/var";             
$lock_file = "$MYHOME/var/amavisd.lock";   
$pid_file  = "$MYHOME/var/amavisd.pid";   
$myhostname = 'mail.free.com'; #我这里是mail.free.com主机

(4).下面是SpamAssassin设定来替换预设的SpamAssassin设置

$sa_tag_level_deflt  = 2.0;  # add spam info headers if at, or above that level  
$sa_tag2_level_deflt = 6.2;  # add 'spam detected' headers at that level   
$sa_kill_level_deflt = 6.9;  # triggers spam evasive actions (e.g. blocks mail)   
$sa_dsn_cutoff_level = 10;   # spam level beyond which a DSN is not sent   
$sa_crediblefrom_dsn_cutoff_level = 18; # likewise, but for a likely valid From   
# $sa_quarantine_cutoff_level = 25; # spam level beyond which quarantine is off   
$penpals_bonus_score = 8;    # (no effect without a @storage_sql_dsn database)   
$penpals_threshold_high = $sa_kill_level_deflt;  # don't waste time on hi spam   
$bounce_killer_score = 100;  # spam score points to add for joe-jobbed bounces
$sa_mail_body_size_limit = 400*1024; # don't waste time on SA if mail is larger  
$sa_local_tests_only = 0;    # only tests which do not require internet access?

说明,默认不需要修改但你得知道它们和意义,可以方便的帮助我们设置垃圾邮件‘

$sa_tag_level_deflt  指定Amavisd-new由哪一个级别开始写入X-Spam-Flag、X-Spam-Score、X-Spam-Status等垃圾邮件资讯标头,假如你想为所有邮件加入资讯标头,请把此值设为 -999
$sa_tag2_level_deflt  指定由哪一个级别开始在垃圾邮件的标头上标签它们
$sa_kill_level_deflt  指定Amavisd-new由哪一个级别开始拦截和扣留邮件。这个用途很大,因为SpamAssassin在预设情况下不会这样做
$sa_dsn_cutoff_level  指定由哪一个级别开始寄件失败通告不会被发送给寄件人。由于多数垃圾邮件寄件者的地址都是伪造的,不为明显的垃圾邮件发送寄件失败通告是最合理的,要不然你只会加剧反向散寄的问题
$sa_quarantine_cutoff_level  指定哪一个级别开始不必扣留垃圾邮件。这个选项预设是被注释掉的,意思是所有邮件都会被扣留

(5).下面是发送通告的邮件地址(默认是管理员邮箱,接收垃圾邮件通告的邮箱)

$virus_admin               = "virusalert\@$mydomain";  # notifications recip.  
$mailfrom_notify_admin     = "virusalert\@$mydomain";  # notifications sender   
$mailfrom_notify_recip     = "virusalert\@$mydomain";  # notifications sender   
$mailfrom_notify_spamadmin = "spam.police\@$mydomain"; # notifications sender

修改为,

$virus_admin               = "postmaster\@$mydomain";  # notifications recip.  
$mailfrom_notify_admin     = "postmaster\@$mydomain";  # notifications sender   
$mailfrom_notify_recip     = "postmaster\@$mydomain";  # notifications sender   
$mailfrom_notify_spamadmin = "postmaster\@$mydomain"; # notifications sender

(6).设置ClamAV的部分

# ### http://www.clamav.net/
#['ClamAV-clamd',   
#  \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"],   
#  qr/\bOK$/m, qr/\bFOUND$/m,   
#  qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],

修改为,
#去掉相关注释就行

# ### http://www.clamav.net/
 ['ClamAV-clamd',   
   \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"],   
   qr/\bOK$/m, qr/\bFOUND$/m,
   qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],

说明,/var/run/clamav/clamd.sock这个设定必须与我们先前在/etc/clamd.conf内输入的LocalSocket /var/run/clamav/clamd.sock设定相一致。

6.修改Postfix配置文件

(1).修改/etc/postfix/master.cf

[root@mail ~]# vim /etc/postfix/master.cf
# ==========================================================================  
# # service type  private unpriv  chroot  wakeup  maxproc command + args   
# #               (yes)   (yes)   (yes)   (never) (100)   
# # ==========================================================================   
# #   
amavisfeed unix    -       -       n       -       2     smtp   
            -o smtp_data_done_timeout=1200   
            -o smtp_send_xforward_command=yes   
            -o smtp_tls_note_starttls_offer=no   
            -o disable_dns_lookups=yes   
            -o max_use=20

说明,请注意在maxproc栏内的数值 2 必须要与/etc/amavisd.conf内的$max_servers设定一致。有关各选项的详细解释请参阅Amavisd-new的文档(vim /usr/share/doc/amavisd-new-2.8.0/README.postfix)。然后我们定义一个专用的服务把邮件重新注入Postfix。我们为此在/etc/postfix/master.cf内加入一个在localhost(127.0.0.1)的tcp 10025端口(/etc/amavisd.conf的预设值)上监听的smtp服务:

# ========================================================================== 
# # service type  private unpriv  chroot  wakeup  maxproc command + args  
# #               (yes)   (yes)   (yes)   (never) (100)  
# # ==========================================================================  
127.0.0.1:10025 inet n    -       n       -       -     smtpd  
            -o content_filter=  
            -o smtpd_delay_reject=no  
            -o smtpd_client_restrictions=permit_mynetworks,reject  
            -o smtpd_helo_restrictions=  
            -o smtpd_sender_restrictions=  
            -o smtpd_recipient_restrictions=permit_mynetworks,reject  
            -o smtpd_data_restrictions=reject_unauth_pipelining  
            -o smtpd_end_of_data_restrictions=  
            -o smtpd_restriction_classes=  
            -o mynetworks=127.0.0.0/8  
            -o smtpd_error_sleep_time=0  
            -o smtpd_soft_error_limit=1001
            -o smtpd_hard_error_limit=1000 
            -o smtpd_client_connection_count_limit=0  
            -o smtpd_client_connection_rate_limit=0  
            -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings  
            -o local_header_rewrite_clients=  
            -o smtpd_milters=  
            -o local_recipient_maps=

注意,以上两项首行前面一定不能有空格,否则会出错!!!

(2).修改/etc/postfix/main.cf加入以下设定来启用邮件过滤

[root@mail ~]# vim /etc/postfix/main.cf
#filter mail
content_filter = amavisfeed:[127.0.0.1]:10024

(3).重启postfix服务

[root@mail ~]# service postfix restart  
Shutting down postfix:                                     [  OK  ]   
Starting postfix:                                          [  OK  ]

7.启动clamd及amavisd服务:

[root@mail ~]# service clamd start  
Starting Clam AntiVirus Daemon: LibClamAV Warning: **************************************************   
LibClamAV Warning: ***  The virus database is older than 7 days!  ***   
LibClamAV Warning: ***   Please update it as soon as possible.    ***   
LibClamAV Warning: **************************************************   
                                                          [  OK  ]
[root@mail ~]# service amavisd start  
Starting Mail Virus Scanner (amavisd):                     [  OK  ]   
[root@mail ~]#

9.测试

(1).利用telnet测试amavisd这个服务正在127.0.0.1:10024上监听

[root@mail ~]# telnet localhost 10024  
Trying ::1...   
telnet: connect to address ::1: Connection refused   
Trying 127.0.0.1...   
Connected to localhost.   
Escape character is '^]'.   
220 [127.0.0.1] ESMTP amavisd-new service ready   
ehlo free.com   
250-[127.0.0.1]   
250-VRFY   
250-PIPELINING   
250-SIZE   
250-ENHANCEDSTATUSCODES   
250-8BITMIME   
250-DSN   
250 XFORWARD NAME ADDR PORT PROTO HELO IDENT SOURCE   
quit   
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel   
Connection closed by foreign host.   
[root@mail ~]#

(2).测试Postfix的smtpd正在127.0.0.1:10025上监听

[root@mail ~]# telnet localhost 10025  
Trying ::1...   
telnet: connect to address ::1: Connection refused   
Trying 127.0.0.1...   
Connected to localhost.   
Escape character is '^]'.   
220 mail.free.com ESMTP Postfix   
ehlo free.com  
250-mail.free.com   
250-PIPELINING   
250-SIZE 10240000   
250-VRFY   
250-ETRN   
250-AUTH PLAIN LOGIN CRAM-MD5   
250-AUTH=PLAIN LOGIN CRAM-MD5   
250-ENHANCEDSTATUSCODES   
250-8BITMIME   
250 DSN   
quit   
221 2.0.0 Bye   
Connection closed by foreign host.   
[root@mail ~]

(3).垃圾邮件的测试

[root@mail ~]#  cd /usr/share/doc/spamassassin-3.3.1/ 
[root@mail spamassassin-3.3.1]# sendmail test@free.com < sample-spam.txt      
[root@mail spamassassin-3.3.1]# tail -f /var/log/maillog   
Jul 11 09:15:46 mail postfix/cleanup[17529]: 6AB1E23776: message-id=<GTUBE1.1010101@example.net>   
Jul 11 09:15:46 mail postfix/qmgr[17492]: 6AB1E23776: from=<root@free.com>, size=1657, nrcpt=1 (queue active)   
Jul 11 09:15:46 mail amavis[17520]: (17520-01) Passed SPAM {RelayedTaggedInbound,Quarantined}, <root@free.com> -> <test@free.com>, quarantine: spam-rnWvh9AXIRB2.gz, Message-ID: <GTUBE1.1010101@example.net>, mail_id: rnWvh9AXIRB2, Hits: 1005.069, size: 933, queued_as: 6AB1E23776, 2403 ms   
Jul 11 09:15:46 mail postfix/smtp[17533]: D927923774: to=<test@free.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.7, delays=0.21/0.07/0.02/2.4, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 6AB1E23776)\

从日志中我们可以看出进行了垃圾邮件过滤,嘿嘿,但效果不明显我们用Webmail测试一下,效果如下,

这就是我们刚才测试的垃圾邮件,嘿嘿!下面我们再发一封测试一下,

这是我们用test@free.com发给loda@free.com的邮件,我们用loda@free.com接收一下看看效果,

可以看到,当loda接收到这封邮件时,被标记为垃圾邮件!至此所有演示全部完成,嘿嘿,下面我们查看一下所启动的所有服务!

10.查看所有的服务与端口

[root@mail spamassassin-3.3.1]# netstat -ntulp  
Active Internet connections (only servers)   
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      1188/mysqld        
tcp        0      0 0.0.0.0:110                 0.0.0.0:*                   LISTEN      1211/dovecot       
tcp        0      0 0.0.0.0:143                 0.0.0.0:*                   LISTEN      1211/dovecot       
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      1050/sshd          
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN      17489/master       
tcp        0      0 0.0.0.0:993                 0.0.0.0:*                   LISTEN      1211/dovecot       
tcp        0      0 0.0.0.0:995                 0.0.0.0:*                   LISTEN      1211/dovecot       
tcp        0      0 127.0.0.1:10024             0.0.0.0:*                   LISTEN      17517/amavisd (mast    
tcp        0      0 127.0.0.1:10025             0.0.0.0:*                   LISTEN      17489/master       
tcp        0      0 :::80                       :::*                        LISTEN      16150/httpd        
tcp        0      0 :::22                       :::*                        LISTEN      1050/sshd          
tcp        0      0 :::25                       :::*                        LISTEN      17489/master       
udp        0      0 0.0.0.0:68                  0.0.0.0:*                               16825/dhclient     
[root@mail spamassassin-3.3.1]#

十三、安装并配置managesieve插件

说明,managesieve插件实现邮件过滤和Vacation功能

1.在Doevecot2.0之后的版本,如果需要做邮件过滤的功能需要dovecot-pigeonhole扩展包的支持,

[root@mail ~]# yum install -y dovecot-pigeonhole

2.配置dovecot配置文件

[root@mail ~]# vim /etc/dovecot/dovecot.conf
protocols = imap pop3 sieve
[root@mail ~]# vim /etc/dovecot/conf.d/15-lda.conf
mail_plugins = quota sieve

3.重新启动dovecot

[root@mail ~]# service dovecot restart  
Stopping Dovecot Imap:                                     [  OK  ]   
Starting Dovecot Imap:                                     [  OK  ]

4. 查看Dovecot监听4190端口

[root@mail ~]# netstat -ntulp | grep 4190  
tcp        0      0 0.0.0.0:4190                0.0.0.0:*                   LISTEN      17998/dovecot      
[root@mail ~]#

5.managesieve配置文件修改,将模板复制成config.inc.php,做如下修改

[root@mail ~]# cd /var/www/html/webmail/plugins/managesieve/  
[root@mail managesieve]# ls   
Changelog  config.inc.php.dist  lib  localization  managesieve.js  managesieve.php  package.xml  skins  tests   
[root@mail managesieve]# cp config.inc.php.dist config.inc.php   
[root@mail managesieve]# vim config.inc.php   
#修改端口为
$rcmail_config['managesieve_port'] = 4190;

6.在主配置文件中使插件生效

[root@mail ~]# vim  /var/www/html/webmail/config/main.inc.php
$rcmail_config['plugins'] = array('managesieve');

7.效果测试

好了测试成功!Roundcubemail 插件很多,有需要的朋友自行增加就行,^_^……

十四、常见问题分析

说明,说实话这个常见问题分析真不好写,因为我并不知道大家会出什么问题,我这里只说明一下我遇到的一些问题!

1.复制的问题

安装或配置时,很多博友都喜欢复制博客中的内容,会带有一此空格或其它字符,配置文件对这些字符特别的敏感有一点字符可能就支出错,这个特别注意,我自己也遇到过好多次,明明配置都一样为什么你行我不行呢?嘿嘿,这个大家得特别留心!

2.postfix 相关

要查看Postfix的当前主要配置文件的存放路径:postconf -n

系统日志:tail -f /var/log/messages
邮件日志:tail -f /var/log/maillog
3.apache相关
apache相关:tail -f /usr/local/httpd/logs/error_log tail -f /usr/local/httpd/logs/suexec_log

注意,大家可以看到我这里apache运行的用户和组是vmail注意修改

[root@mail ~]# ps aux | grep httpd  
root     16150  0.0  0.0 317840   100 ?        Ss   05:59   0:01 /usr/sbin/httpd   
vmail    16152  0.0  6.5 430908 15428 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16153  0.0  7.2 429640 17184 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16154  0.0  6.2 428340 14884 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16155  0.0  6.6 428624 15672 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16156  0.0  5.9 425644 14120 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16157  0.0  5.9 425368 14124 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16158  0.0  7.2 428068 17224 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    16159  0.0  4.1 420924  9792 ?        S    05:59   0:04 /usr/sbin/httpd   
vmail    17061  0.0  6.4 427112 15280 ?        S    07:04   0:03 /usr/sbin/httpd   
vmail    17545  0.0  6.2 426612 14804 ?        S    09:18   0:02 /usr/sbin/httpd   
root     18152  0.0  0.3 103236   864 pts/1    S+   10:02   0:00 grep httpd   
[root@mail ~]#

修改方法,

[root@mail ~]# vim /etc/httpd/conf/httpd.conf
User vmail  
Group vmail

4.mysql相关
mysql相关: tail -f /usr/local/mysql/data/linux.linux.com.err

5.垃圾邮件相关
测试amavisd: amavisd -d config debug-sa

[root@mail ~]# amavisd -d config debug-sa   
The amavisd daemon is already running, PID: [17517]

测试spam: spamassassin -D –lint

[root@mail ~]# spamassassin -D --lint

6.clamd相关

查看  /var/log/clamav/clamd.log

[root@mail ~]# tail -f /var/log/clamav/clamd.log  
Thu Jul 11 09:10:39 2013 -> PDF support enabled.   
Thu Jul 11 09:10:39 2013 -> HTML support enabled.   
Thu Jul 11 09:10:39 2013 -> Self checking every 600 seconds.   
Thu Jul 11 09:22:02 2013 -> No stats for Database check - forcing reload   
Thu Jul 11 09:22:10 2013 -> Reading databases from /var/clamav   
Thu Jul 11 09:22:14 2013 -> Database correctly reloaded (1258735 signatures)   
Thu Jul 11 09:39:24 2013 -> SelfCheck: Database status OK.   
Thu Jul 11 09:49:24 2013 -> SelfCheck: Database status OK.   
Thu Jul 11 09:59:24 2013 -> SelfCheck: Database status OK.   
Thu Jul 11 10:09:24 2013 -> SelfCheck: Database status OK.

更新病毒库 freshclam

[root@mail clamav]# freshclam  
ClamAV update process started at Thu Jul 11 10:13:58 2013   
WARNING: Your ClamAV installation is OUTDATED!   
WARNING: Local version: 0.97.7 Recommended version: 0.97.8   
DON'T PANIC! Read http://www.clamav.net/support/faq
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)   
WARNING: getfile: daily-15077.cdiff not found on remote server (IP: 202.118.1.40)   
WARNING: getpatch: Can't download daily-15077.cdiff from db.cn.clamav.net   
WARNING: getfile: daily-15077.cdiff not found on remote server (IP: 200.236.31.1)   
WARNING: getpatch: Can't download daily-15077.cdiff from db.cn.clamav.net   
WARNING: getpatch: Can't download daily-15077.cdiff from db.cn.clamav.net   
WARNING: Incremental update failed, trying to download daily.cvd   
Downloading daily.cvd [100%]   
daily.cvd updated (version: 17485, sigs: 1458626, f-level: 63, builder: guitar)   
Downloading bytecode.cvd [100%]   
bytecode.cvd updated (version: 214, sigs: 41, f-level: 63, builder: neo)   
Database updated (2503054 signatures) from db.cn.clamav.net (IP: 202.118.1.40)   
Clamd successfully notified about the update.   
[root@mail clamav]#

查看更新日志

tail -f /var/log/clamav/freshclam.log

7.dovecot 相关

测试:telnet localhost 110  telnet localhost 143

8.总结

若发现某个服务个有问题或不能收发邮件,最好的方法就是查看相关日志文件,基本都上都是有记录的,只要发现错误,我们便能很快的解决问题!本人水平有限,只能说这么多了,嘿嘿!

来源: http://blog.51cto.com/freeloda/1246350
发表在 mail | 标签为 | CentOS6.4+LAMP+Postfix+Dovecot+Postfixadmin+Roundcubemail (2)已关闭评论

CentOS6.4+LAMP+Postfix+Dovecot+Postfixadmin+Roundcubemail (1)

大纲

一、mail 协议

二、mail 组件

三、mail 工作原理(两种对比)

四、安装前的准备工作

五、安装并配置LAMP环境

六、安装并配置postfixadmin

七、安装并配置phpmyadmin

八、配置postfix邮件发送代理

九、安装并配置dovecot邮件检索代理

十、测试SMTP与POP3服务

十一、安装并配置WebMail(Roundcubemail)

十二、安装并配置病毒扫描与垃圾邮件过滤

十三、安装并配置managesieve插件

十四、常见问题分析

注:系统,CentOS 6.4 X86_64 。软件,全部都是RPM包,有兴趣的博友可以尝试一下全部源码包安装!(所安装的主要软件如下,LAMP+Postfix+Dovecot+PostfixAdmin+Roundcubemail+Amavisd-new+ClamAV+SpamAssassin+Managesieve)

一、mail 协议

mail使用的协议有,

协议名称 协议类型 端口号
smtp tcp 25
pop3 tcp 110
smtps tcp 465
pop3s tcp 995
imap tcp 143
imaps tcp 993

二、mail 组件

1.MTA:mail transfer agent 邮件传输代理

常见软件,

Exchange(微软)
Sendmail 开源的软件 目前有50%的邮件服务器使用这个软件
Postfix  现在用的挺多
Qmail    昙花一现
Exim(英国剑桥大学开发的)

2.MRA:mail retravial agent 邮件检索代理

常见软件,

courier-imap:pop3,imap4,imaps,pop3s (俄罗斯开发)
dovecot (主流)

3.MDA:mail delivery agent 邮件投递代理

常见软件,

procmail (postfix默认)
maildrop (功能强大,效率高)

4.MUA:mail user agent 邮件用户代理

常见软件,

outlook express
Foxmail
pine(linux)
mutt(linux,经常用到的)

5.Mailbox 信箱

mailbox
maildir (主流)
两者的主要区别,mailbox是把所有邮件放在同一个文件中,maildir把每个用户的邮件都单独存放

三、mail 工作原理

1.常规架构

如下图,

各组件具体说明

(1).常用的客户端

Mail Client:outlook,foxmail等
Web Browser:IE,Firefox,Chrome等

(2).Postfix,最常用的MTA,我们通过postfix来发送邮件

(3).Dovecot,最常用的MRA,我们通过dovecot来收发邮件

(4).amavisd-new,可以理解成一个代理,Postfix把邮件交给他,他负责联系杀毒和反垃圾

(5).SpamAssassin,防垃圾邮件,是邮件系统的基本功能,SpamAssassin,是最有名的,尤其是和Amavisd ClamAV结合起来,这是一个经得起考虑的组合

(6).ClamAV,对邮件进行病毒扫描

(7).Cyrus-SASL,认证函数库

(8).Courier-Authlib,调用mysql数据库进行认证

(9).WebMail,通过浏览器来管理收发邮件

(10).OpenLDAP或MySQL,虚拟用户或虚拟域的存放数据库

(11).Maildir或Mailbox,用来存放用户邮件,两者的区别在于maildir为每个用户单独存放邮件,mailbox是所有邮件都存放在同一文件

(12).phpLDAPadmin,管理LDAP工具,用来管理虚拟用户与虚拟域

2.具体工作流程

(1). 当邮件通过outlook或foxmail发送到服务器的25端口,postfix接受连接,它会做一些基本检查

  • 发送者是否在黑名单或者实时黑名单,如果在黑名单,马上拒绝
  • 是否是授权用户,是授权可以进行转发
  • 接收者是否是服务器的用户,在这里postfix调用Cyrus-SASL认证函数库,并通过Courier-Authlib去mysql数据中验证用户,如果不是,马上拒绝
  • 如果我们启用了灰名单,会进行判断是否会拒绝邮件或者接收

(2).postfix 把邮件通过10024端口交给amavis来处理,注意amavis,只会检查邮件而不会丢弃或者拒绝邮件(如上图)

(3).amavis调用SpamAssassin检查邮件是否是spam,如果SpamAssassin认为邮件是垃圾邮件,会给邮件打上标记spam(如下图)

(注:大家会看到,只会给邮件打上spam标记,我们还是可以收到这个邮件的)

(4).amavis调用ClamAV,看邮件是否含有病毒

(5).amavis把检查完的邮件,通过10025端口重新把邮件交回给postfix

(6).postfix把邮件交给LDA(local delivery agent),LDA是负责本地邮件投放到用户的邮箱,postfix默认使用 procmail 投递邮件(我们也可以使用其它投递代理如,maildrop)到 用户的邮箱并以maildir的方式存放在硬盘上

(7).用户使用邮件客户端,通过pop3或imap协议进行连接并管理邮件,webmail 是通过imap的方式来读取或管理邮件

总结,从上面的工作流程我们可以看到用Cyrus-SASL,Courier-authlib,Maildrop太麻烦了。一大堆组件,邮件系统本来就很杂。我以能简单则简单的原则进行了精简而且效率更高,Dovecot目前已经实现了SASL,而且Dovecot的SASL能够自动CACHE查询结果,这个是比较好的。并且Dovecot还可以当LDA使用。而Postfix也支持Dovecot的SASL验证。Postfix可以直接使用Dovecot的后台认证,不需要分开配置。(如果使用Courier,我们必须安装配置额外的认证软件,比如Saslauthd,配置这个,会是一个恶梦,如果出现问题,很难排错),并且Dovecot,可以很方便实现磁盘配额的功能。Dovecot作为Courier的可替换组件,Dovecot在磁盘读写量上比Courier减少25%左右,内存占用也比Courier节省10%到70%不等。好了,说了这么多下面我们来看一下,我们的精简架构!

3.精简架构

经过与上面的对比我们明显看到简单了许多,嘿嘿!下面我们说一下具体的工作流程,

(1).当邮件发送到服务器的25端口,postfix接受连接,它会做一些基本检查

  • 发送者是否在黑名单或者实时黑名单,如果在黑名单,马上拒绝
  • 是否是授权用户,是授权用户可以进行转发
  • 接收者是否是服务器的用户,Postfix通Dovecot提供的SASL进行认证,如果不是,马上拒绝
  • 如果我们启用了灰名单,会进行判断是否会拒绝邮件或者接收

(2).postfix 把邮件通过10024端口交给amavis来处理,注意amavis,只会检查邮件而不会丢弃或者拒绝邮件

(3).amavis调用SpamAssassin检查邮件是否是spam,如果SpamAssassin认为邮件是垃圾邮件,会给邮件打上标记spam(同上)

(4).amavis调用ClamAV,看邮件是否含有病毒

(5).amavis把检查完的邮件,通过10025端口重新把邮件交回给postfix

(6).postfix把邮件交给LDA(local delivery agent),LDA是负责本地邮件投放到用户的邮箱,(我们这里使用dovecot提供的LDA功能,而不是postfix提供的LDA)邮件会进入用户的邮箱,Dovecot会执行用户设置的filter,也就是Dovecot通过调用Sieve,放到相关的文件夹

(7).Dovecot 把邮件以maildir的方式存放在硬盘上。

(8).用户使用邮件客户端,通过pop3或imap协议进行连接。Webmail(RoundCubeMail),是通过imap的方式来读取邮件。

总结,经过上面的简单说明你应该知道整个邮件系统的工作流程了,下面我们将完整的搭建这套企业级的邮件系统!^_^……

四、安装前的准备工作

1.关闭防火墙与SELinux

[root@mail ~]# service iptables stop
iptables:清除防火墙规则:                                 [确定]
iptables:将链设置为政策 ACCEPT:filter                    [确定]
iptables:正在卸载模块:                                   [确定]
[root@mail ~]# service ip6tables stop
ip6tables:清除防火墙规则:                                [确定]
ip6tables:将 chains 设置为 ACCEPT 策略:filter            [确定]
:正在卸载模块:                                           [确定]
[root@mail ~]# chkconfig iptables off
[root@mail ~]# chkconfig ip6tables off
[root@mail ~]# vim /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted
[root@mail ~]# reboot

2.修改主机名

[root@mail ~]# vim /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=mail.free.com
[root@mail ~]# reboot

3.下载并安装yum源

(1).163的yum源

(2).rpmforge软件仓库

[root@mail ~]# wget http://mirrors.163.com/.help/CentOS6-Base-163.repo
[root@mail ~]# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
[root@mail ~]# ls
anaconda-ks.cfg  CentOS6-Base-163.repo  install.log  install.log.syslog  rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

(3).备份原有的yum源

[root@mail ~]# cd /etc/yum.repos.d/
[root@mail yum.repos.d]# ls
CentOS-Base.repo  CentOS-Debuginfo.repo  CentOS-Media.repo  CentOS-Vault.repo
[root@mail yum.repos.d]# mkdir backup
[root@mail yum.repos.d]# mv CentOS-* backup/
[root@mail yum.repos.d]# ls
backup
[root@mail yum.repos.d]#

(4). 增加新的yum源

[root@mail ~]# cp CentOS6-Base-163.repo /etc/yum.repos.d/
[root@mail ~]# rpm -ivh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
warning: rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY
Preparing...                ########################################### [100%]
   1:rpmforge-release       ########################################### [100%]
[root@mail ~]# ll /etc/yum.repos.d/
总用量 24
drwxr-xr-x 2 root root 4096 7月  10 22:00 backup
-rw-r--r-- 1 root root 2006 7月  10 22:01 CentOS6-Base-163.repo
-rw-r--r-- 1 root root  739 11月 13 2010 mirrors-rpmforge
-rw-r--r-- 1 root root  717 11月 13 2010 mirrors-rpmforge-extras
-rw-r--r-- 1 root root  728 11月 13 2010 mirrors-rpmforge-testing
-rw-r--r-- 1 root root 1113 11月 13 2010 rpmforge.repo
[root@mail ~]#

(5).清理yum缓存并更新系统

[root@mail ~]# yum clean all
Loaded plugins: fastestmirror
Cleaning repos: base extras rpmforge updates
Cleaning up Everything
Cleaning up list of fastest mirrors
[root@mail ~]# yum update

4.创建一个vmail用户,用作管理虚拟邮箱的文件夹

useradd -u 2000 -d /var/vmail -m -s /sbin/nologin vmail

五、安装并配置LAMP环境

说明:最新的PostfixAdmin2.3.6+Roundcubemail0.92的PHP环境要求是最低是PHP5.2,我这里RPM安装的是5.3.3

1.安装LAMP环境

[root@mail ~]#yum -y install httpd mysql mysql-devel mysql-server php php-pecl-Fileinfo php-mcrypt php-devel php-mysql php-common php-mbstring php-gd php-imap php-ldap php-odbc php-pear php-xml php-xmlrpc pcre pcre-devel

2.整合Apache与PHP

[root@mail ~]# vim /etc/httpd/conf/httpd.conf
#增加下面现行
AddType application/x-httpd-php .php #apache解析php程序
PHPIniDir "/etc/php.ini" #指定php.ini配置文件路径
#修改这一行增加index.php
DirectoryIndex index.php index.html index.html.var
#修改apache运行的用户和组
User vmail
Group vmail

3.测试

[root@mail ~]# vim /var/www/html/index.php
<?
        phpinfo();
?>
[root@mail ~]# service httpd start
正在启动 httpd:httpd: Could not reliably determine the server's fully qualified domain name, using mail.free.com for ServerName
                                                           [确定]
[root@mail ~]#
注:会有个警告
[root@mail ~]# vim /etc/httpd/conf/httpd.conf
#增加一行
ServerName localhost:80
[root@mail ~]# service httpd restart #重新启动不会再有警告
停止 httpd:                                               [确定]
正在启动 httpd:                                           [确定]
[root@mail html]# chkconfig httpd on #加入开机自启动
[root@mail html]# chkconfig httpd --list
httpd           0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭
[root@mail html]#

测试效果如下,

看到这个图说明LAMP环境安装成功了,嘿嘿!顺便可以看一下imap这个很重要,嘿嘿!

六、安装并配置postfixadmin

1.查看所需软件

[root@mail ~]# ll
总用量 12804
-rw-------. 1 root root     970 6月  20 05:03 anaconda-ks.cfg
-rw-r--r--  1 root root    2006 9月   1 2011 CentOS6-Base-163.repo
-rw-r--r--. 1 root root   15709 6月  20 05:03 install.log
-rw-r--r--. 1 root root    4178 6月  20 05:01 install.log.syslog
-rw-r--r--  1 root root 7728693 7月   7 18:48 phpMyAdmin-4.0.4.1-all-languages.zip
-rw-r--r--  1 root root 1597001 7月   7 12:56 postfixadmin-2.3.6.tar.gz
-rw-r--r--  1 root root 3735505 7月   7 12:57 roundcubemail-0.9.2.tar.gz
-rw-r--r--  1 root root   12700 11月 13 2010 rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
[root@mail ~]#

2.解压并修改文件名

[root@mail ~]# tar xf postfixadmin-2.3.6.tar.gz -C /var/www/html/
[root@mail ~]# cd /var/www/html/
[root@mail html]# ls
index.php  postfixadmin-2.3.6
[root@mail html]# mv postfixadmin-2.3.6 postfixadmin
[root@mail html]# ls
index.php  postfixadmin
[root@mail html]#

3.配置并测试

[root@mail html]# cd postfixadmin/
#修改前先备份一下配置文件
[root@mail postfixadmin]# cp config.inc.php config.inc.php.bak
[root@mail postfixadmin]# cp setup.php setup.php.bak
[root@mail postfixadmin]# vim config.inc.php
#找到下面几行并修改
$CONF['configured'] = true;
$CONF['database_type'] = 'mysql';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'postfix';
$CONF['database_password'] = 'postfix';
$CONF['database_name'] = 'postfix';
$CONF['admin_email'] = 'postmaster@free.com';
$CONF['encrypt'] = 'dovecot:CRAM-MD5';
$CONF['dovecotpw'] = "/usr/bin/doveadm pw";
$CONF['domain_path'] = 'YES';
$CONF['domain_in_mailbox'] = 'NO';
$CONF['aliases'] = '1000';
$CONF['mailboxes'] = '1000';
$CONF['maxquota'] = '1000';
$CONF['fetchmail'] = 'NO';
$CONF['quota'] = 'YES';
$CONF['used_quotas'] = 'YES';
$CONF['new_quota_table'] = 'YES';

4.为postfixadmin创建Mysql数据库与权限

[root@mail html]# service mysqld start
[root@mail html]# chkconfig mysqld on #加入开机自启动
[root@mail html]# chkconfig mysqld --list
mysqld          0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭
[root@mail html]#
[root@mail ~]# mysql
mysql> create database postfix;
mysql> grant all on postfix.* to postfix@'localhost' identified by 'postfix';
mysql> flush privileges;

测试一下能不能登录,

[root@mail html]# mysql -upostfix -ppostfix
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.1.69 Source distribution
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| postfix            |
| test               |
+--------------------+
3 rows in set (0.00 sec)
mysql>
测试成功可能登录!

5.修改所有者与所有组

[root@mail html]# chown -R vmail.vmail postfixadmin/
[root@mail html]# ll
总用量 8
-rw-r--r--  1 root  root    18 7月  10 22:18 index.php
drwxrwxr-x 14 vmail vmail 4096 7月  10 22:57 postfixadmin
[root@mail html]#

6.具体配置过程如下图

(1).http://192.168.18.187/postfixadmin/setup.php

注:检查PHP环境,并初始化数据库

(2).创建设置密码并修改配置文件(我这里的密码是123456)

[root@mail postfixadmin]# vim config.inc.php    
$CONF['setup_password'] = '6471f6462d427bf547c07fb2a08fdecf:09a43f1679223
4050d298b7d0333c101d4bbd48e';

(3).创建管理员密码

先输入你刚才设置的密码,我这里是123456,然后输入管理员邮箱,我管理员密码!

出现错误,说没有dovecotpw,是因为我们还没安装dovecot,我们这里先来安装一下dovecot,后面再进行配置!

[root@mail postfixadmin]# yum install -y  dovecot dovecot-devel dovecot-mysql
[root@mail postfixadmin]# chkconfig dovecot on #加入开机自启动
[root@mail postfixadmin]# chkconfig dovecot --list
dovecot         0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭
[root@mail postfixadmin]#

我们再来设置一下管理员的账户与密码,(我这里设置是postmaster@free.com 密码:admin)

看这次设置成功,下面我们管理账户登录一下

http://192.168.18.187/postfixadmin/login.php

7.postfxiadmin不能自动创建目录,所以我们得增加自动建立目录的功能

(1).建立创建虚拟邮箱脚本,脚本名称 /usr/local/bin/maildir-creation.sh,脚本内容如下:

[root@mail ~]#vim /usr/local/bin/maildir-creation.sh
#!/bin/bash
#
HOME_DIR="/var/vmail"
USER_NAME="vmail"
GROUP_NAME="vmail"
if [ ! -d ${HOME_DIR}/$1 ] ; then
    mkdir ${HOME_DIR}/$1
    chown -R ${USER_NAME}.${GROUP_NAME} ${HOME_DIR}/$1
fi
mkdir ${HOME_DIR}/$1/$2
chown -R ${USER_NAME}.${GROUP_NAME} ${HOME_DIR}/$1/$2

(2).建立删除虚拟邮箱脚本,脚本名称 /usr/local/bin/maildir-deletion.sh ,脚本内容如下:

[root@mail ~]#vim /usr/local/bin/maildir-deletion.sh
#!/bin/bash
#
# vmta ALL = NOPASSWD: /usr/local/bin/maildir-deletion.sh
#
if [ $# -ne 2 ] ; then
  exit 127
fi
DOMAIN="$1"
USER="$2"
HOME_DIR="/var/vmail"
USER_DIR="${HOME_DIR}/${DOMAIN}/${USER}"
TRASH_DIR="${HOME_DIR}/deleted-maildirs"
DATE=`date "+%Y%m%d_%H%M%S"`
if [ ! -d "${TRASH_DIR}/${DOMAIN}" ] ; then
    mkdir -p "${TRASH_DIR}/${DOMAIN}"
fi
if [ -d "${USER_DIR}" ] ; then
    mv ${USER_DIR} ${TRASH_DIR}/${DOMAIN}/${USER}-${DATE}
fi

8.建立删除目录

[root@mail ~]# mkdir /var/vmail/deleted-maildirs
[root@mail ~]# chown -R vmail.vmail /var/vmail/deleted-maildirs/

9.赋予脚本可执行权限

[root@mail ~]# chmod 750 /usr/local/bin/maildir-*
[root@mail ~]# chown vmail.vmail /usr/local/bin/maildir-*

10.配置sudo

[root@mail ~]#vim /etc/sudoers
#在 /etc/sudoers 最后增加两行
vmail ALL = NOPASSWD: /usr/local/bin/maildir-creation.sh
vmail ALL = NOPASSWD: /usr/local/bin/maildir-deletion.sh
#在/etc/sudoers 注释掉下面内容
#Defaults    requiretty
:wq! #由于这个文件是只读的,所以得强制保存并退出

11.修改postfixadmin的相关文件

[root@mail ~]# cd /var/www/html/postfixadmin/
[root@mail postfixadmin]# vim create-mailbox.php
修改create-mailbox.php 文件,229行内容应该是:
db_log ($SESSID_USERNAME, $fDomain, 'create_mailbox', "$fUsername");
在该行前面增加下面一行,
system("sudo /usr/local/bin/maildir-creation.sh $fDomain ".$_POST['fUsername']);
[root@mail postfixadmin]# vim delete.php
修改delete.php 文件,146行内容应该是,
db_log ($SESSID_USERNAME, $fDomain, 'delete_mailbox', $fDelete);
在该行下面增加下面4行,
$userarray=explode("@",$fDelete);
$user=$userarray[0];
$domain=$userarray[1];
system("sudo /usr/local/bin/maildir-deletion.sh $domain $user");

好了至此postfixadmin配置全部完成,^_^……

七、安装并配置phpmyadmin

1.解压并重命令

[root@mail ~]# unzip phpMyAdmin-4.0.4.1-all-languages.zip
[root@mail ~]# mv phpMyAdmin-4.0.4.1-all-languages /var/www/html/
[root@mail ~]# cd /var/www/html/
[root@mail html]# ls
index.php  phpMyAdmin-4.0.4.1-all-languages  postfixadmin
[root@mail html]# mv phpMyAdmin-4.0.4.1-all-languages phpmyadmin
[root@mail html]# ls
index.php  phpmyadmin  postfixadmin
[root@mail html]#

2.修改配置文件

[root@mail html]# cd phpmyadmin/
[root@mail phpmyadmin]# cp config.sample.inc.php config.inc.php     
[root@mail phpmyadmin]#

3.给phpmyadmin授权

mysql> grant all on *.* to root@'localhost' identified by '123456';
Query OK, 0 rows affected (0.03 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)

4.测试

好了,登录成功,现在我们就可以用phpmyadmin来管理mysql数据库了,嘿嘿!

八、配置postfix邮件发送代理

注:Postfix用CentOS6.4系统自带的,因为CentOS6.4里面的postfix包已经支持mysql

1.查看postfix版本

[root@mail postfixadmin]# rpm -qa | grep postfix
postfix-2.6.6-2.2.el6_1.x86_64

2.配置postfix

[root@mail ~]# vim /etc/postfix/main.cf
#基本配置
myhostname = mail.free.com
mydomain = free.com
myorigin = $mydomain
inet_interfaces = all
mynetworks_style = host
mynetworks = 192.168.18/24, 127.0.0.0/8
#虚拟域名配置
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
# Additional for quota support
virtual_create_maildirsize = yes
virtual_mailbox_extended = yes
virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql_virtual_mailbox_limit_maps.cf
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = Sorry, this user has exceeded their disk space quota, please try again later.
virtual_overquota_bounce = yes
#Specify the user/group that owns the mail folders. I'm not sure if this is strictly necessary when using Dovecot's LDA.
virtual_uid_maps = static:2000
virtual_gid_maps = static:2000
#Specifies which tables proxymap can read: http://www.postfix.org/postconf.5.html#proxy_read_maps
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
[root@mail ~]# postconf #检查配置文件是否有错误

3.创建Mysql脚本(注意用户名和密码、DBNAME,我这里全是postfix)
(1).创建/etc/postfix/mysql_virtual_domains_maps.cf文件

[root@mail ~]# vim /etc/postfix/mysql_virtual_domains_maps.cf
user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%s' AND active = '1'
#optional query to use when relaying for backup MX
#query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = '0' AND active = '1'

(2).创建/etc/postfix/mysql_virtual_alias_maps.cf文件

[root@mail ~]# vim /etc/postfix/mysql_virtual_alias_maps.cf
user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias WHERE address='%s' AND active = '1'

(3).创建/etc/postfix/mysql_virtual_mailbox_maps.cf文件

[root@mail ~]# vim /etc/postfix/mysql_virtual_mailbox_maps.cf
user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT CONCAT(domain,'/',maildir) FROM mailbox WHERE username='%s' AND active = '1'

(4).创建/etc/postfix/mysql_virtual_mailbox_limit_maps.cf文件

[root@mail ~]# vim /etc/postfix/mysql_virtual_mailbox_limit_maps.cf
user = postfix
password = postfix
hosts = localhost
dbname = postfix
query = SELECT quota FROM mailbox WHERE username='%s' AND active = '1'

4.SMTP 认证设定

(1).查看postfix支持的认证,默认支持dovecot

[root@mail ~]# postconf -a
cyrus
dovecot

(2).修改/etc/postfix/main.cf配置文件

[root@mail ~]#vim /etc/postfix/main.cf
#SASL SUPPORT FOR CLIENTS
# Turns on sasl authorization
smtpd_sasl_auth_enable = yes
#Use dovecot for authentication
smtpd_sasl_type = dovecot
# Path to UNIX socket for SASL
smtpd_sasl_path = /var/run/dovecot/auth-client
#Disable anonymous login. We don't want to run an open relay for spammers.
smtpd_sasl_security_options = noanonymous
#Adds support for email software that doesn't follow RFC 4954.
#This includes most versions of Microsoft Outlook before 2007.
broken_sasl_auth_clients = yes
#
smtpd_recipient_restrictions =  permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

5.使用Dovecot做为投递

[root@mail ~]# vim /etc/postfix/main.cf
# TRANSPORT MAP
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
#修改master.cf文件
[root@mail ~]# vim /etc/postfix/master.cf
#在最后增加这两行,注意flags前面有两个空格,不然会报错
dovecot   unix  -       n       n       -       -       pipe,
  flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}

九、安装并配置dovecot邮件检索代理

说明:dovecot 1.X 与 dovecot 2.X配置文件的区别,1.X所以的配置都在同文件中而2.X是多个文件存放的(/etc/dovecot/dovecot.conf 和 /etc/dovecot/conf.d/),所有2.X配置文件比较分散,我把需要修改的配置文件的内容列出来

1.修改dovecot配置文件

(1).修改/etc/dovecot/dovecot.conf #主配置文件

[root@mail ~]# vim /etc/dovecot/dovecot.conf
protocols = imap pop3
listen = *
dict {
  quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
!include conf.d/*.conf

(2).修改/etc/dovecot/conf.d/10-auth.conf

[root@mail ~]# vim /etc/dovecot/conf.d/10-auth.conf
disable_plaintext_auth = no
auth_mechanisms = plain login cram-md5
!include auth-sql.conf.ext

(3).修改/etc/dovecot/conf.d/10-mail.conf

[root@mail ~]# vim /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:%hMaildir
mbox_write_locks = fcntl

(4).修改/etc/dovecot/conf.d/10-master.conf

[root@mail ~]# vim /etc/dovecot/conf.d/10-master.conf
service imap-login {
  inet_listener imap {
  }
  inet_listener imaps {
  }
}
service pop3-login {
  inet_listener pop3 {
  }
  inet_listener pop3s {
  }
}
service lmtp {
  unix_listener lmtp {
  }
}
service imap {
}
service pop3 {
}
service auth {
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    group = vmail
  }
#新加下面一段,为smtp做认证
  unix_listener auth-client {
    mode = 0600
    user = postfix
    group = postfix
  }
}
service auth-worker {
}
service dict {
  unix_listener dict {
    mode = 0600
    user = vmail
    group = vmail
  }
}

(5).修改/etc/dovecot/conf.d/15-lda.conf

[root@mail ~]# vim /etc/dovecot/conf.d/15-lda.conf
protocol lda {
  mail_plugins = quota
  postmaster_address = postmaster@free.com #管理员邮箱
}

(6).修改/etc/dovecot/conf.d/20-imap.conf

[root@mail ~]# vim /etc/dovecot/conf.d/20-imap.conf
protocol imap {
        mail_plugins = quota imap_quota
}

(7).修改/etc/dovecot/conf.d/20-pop3.conf

[root@mail ~]# vim /etc/dovecot/conf.d/20-pop3.conf
protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
  mail_plugins = quota
}

(8).修改/etc/dovecot/conf.d/90-quota.conf

[root@mail ~]# vim /etc/dovecot/conf.d/90-quota.conf
plugin {
  quota_rule = *:storage=1G
}
plugin {
}
plugin {
  quota = dict:User quota::proxy::quota
}
plugin {
}

(9).增加/etc/dovecot/dovecot-sql.conf.ext

[root@mail ~]# vim /etc/dovecot/dovecot-sql.conf.ext
driver = mysql
connect = host=localhost dbname=postfix user=postfix password=postfix
default_pass_scheme = CRAM-MD5
user_query = SELECT CONCAT('/var/vmail/', maildir) AS home, 2000 AS uid, 2000 AS gid, CONCAT('*:bytes=', quota) as quota_rule FROM mailbox WHERE username = '%u' AND active='1'
password_query = SELECT username AS user, password, CONCAT('/var/vmail/', maildir) AS userdb_home, 2000 AS userdb_uid, 2000 AS userdb_gid, CONCAT('*:bytes=', quota) as userdb_quota_rule FROM mailbox WHERE username = '%u' AND active='1'

(10).增加/etc/dovecot/dovecot-dict-sql.conf.ext

[root@mail ~]# vim /etc/dovecot/dovecot-dict-sql.conf.ext
connect = host=localhost dbname=postfix user=postfix password=postfix
map {
  pattern = priv/quota/storage
  table = quota2
  username_field = username
  value_field = bytes
}
map {
  pattern = priv/quota/messages
  table = quota2
  username_field = username
  value_field = messages
}

2.重新启动服务

[root@mail ~]# service postfix restart
关闭 postfix:                                             [确定]
启动 postfix:                                             [确定]
[root@mail ~]# service dovecot restart
停止 Dovecot Imap:                                        [失败]
正在启动 Dovecot Imap:                                    [确定]

至此dovecot配置全部完成,^_^ ……
十、测试SMTP与POP3服务

1.postfixadmin创建虚拟域

注:新建free.com测试域!

2.postfixadmin创建测试箱

注:新建test@free.com和loda@free.com两个测试邮箱!

3.测试连接25端口

[root@mail ~]# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 mail.free.com ESMTP Postfix
ehlo free.com
250-mail.free.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN CRAM-MD5
250-AUTH=PLAIN LOGIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
Connection closed by foreign host.
[root@mail ~]#

注:连接成功!

4.测试连接110端口

[root@mail ~]# telnet localhost 110
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK Dovecot ready.
user 123@free.com
+OK
pass 123456
+OK Logged in.
quit
+OK Logging out.
Connection closed by foreign host.
[root@mail ~]#
注:可以看到,认证成功并登录成功!

5.查看自动创建的邮箱

[root@mail ~]# cd /var/vmail/
[root@mail vmail]# ll
总用量 8
drwxr-xr-x 2 vmail vmail 4096 7月  11 00:07 deleted-maildirs
drwx------ 3 vmail vmail 4096 7月  11 01:17 free.com
[root@mail vmail]# cd free.com/
[root@mail free.com]# ls
123
[root@mail free.com]#

注:已自动创建脚本,说明我们上面的脚本执行成功!

6.foxmail客户端测试收发邮件

如图,test@free.com 发给 loda@free.com 邮件

loda@free.com 成功收到邮件!

详细内容如下,

测试成功能发能收!

7.问题说明

如下图,当我们执行postfixadmin的备份,会出现以下警告,并不能实现备份!

从上图中我们可以看出,data.timezone时区问题引起的,下面我们就来解决一下!

(1).修改/var/www/html/admin/backup.php文件

[root@mail admin]# vim /var/www/html/admin/backup.php
#增加一行(如下图)
date_default_timezone_set('PRC');

(2).效果如下

注:postfixadmin备份成功!到此一个完整的邮件系统已完成,但是为了方便的浏览和管理文件,我们下面安装一下WebMail!

十一、安装并配置WebMail(Roundcubemail)

1.解压并重命名

[root@mail ~]# tar -xf roundcubemail-0.9.2.tar.gz -C /var/www/html/
[root@mail ~]# cd /var/www/html/
[root@mail html]# ls
admin  index.php  phpmyadmin  roundcubemail-0.9.2
[root@mail html]# mv roundcubemail-0.9.2 webmail
[root@mail html]# ls
admin  index.php  phpmyadmin  webmail
[root@mail html]#

2.配置WebMail

从图上可以看出date.timezone报错,下面我们来修正一下!

3.修改php.ini

[root@mail installer]# vim /etc/php.ini
date.timezone = Asia/Shanghai

4.修改apache中PHPini的位置

[root@mail installer]# vim /etc/httpd/conf/httpd.conf
PHPIniDir "/etc/php.ini"
[root@mail installer]# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
[root@mail installer]#

5.修改所有Web文件的所属者与所属组

[root@mail ~]# cd /var/www/html/
[root@mail html]# ll
total 16
drwxrwxr-x 14 1000 1010 4096 Jul 11 05:25 admin
-rw-r--r--  1 root root   18 Jul 11 04:12 index.php
drwxr-xr-x  9 root root 4096 Jul 11 04:17 phpmyadmin
drwxr-xr-x 11  501   80 4096 Jun 16 23:10 webmail
[root@mail html]# chown -R vmail.vmail admin
[root@mail html]# chown -R vmail.vmail phpmyadmin
[root@mail html]# chown -R vmail.vmail webmail
[root@mail html]# ll
total 16
drwxrwxr-x 14 vmail vmail 4096 Jul 11 05:25 admin
-rw-r--r--  1 root  root    18 Jul 11 04:12 index.php
drwxr-xr-x  9 vmail vmail 4096 Jul 11 04:17 phpmyadmin
drwxr-xr-x 11 vmail vmail 4096 Jun 16 23:10 webmail

6.查看session保存位置

[root@mail html]# vim /etc/php.ini
session.save_path = "/var/lib/php/session"

7.修改session文件的所属组

[root@mail html]# cd /var/lib/php/
[root@mail php]# ll
total 4
drwxrwx--- 2 root apache 4096 Feb 22 10:56 session
[root@mail php]# chown -R .vmail session/
[root@mail php]# ll
total 4
drwxrwx--- 2 root vmail 4096 Feb 22 10:56 session
[root@mail php]#

8.效果如下

9.单击NEXT我们继续进行设置(下面是必须配置的选项)

(1).配置webmail的显示名称

(2).配置Webmail数据库相关(我这里全部设置是,roundcubemail)

(3).配置IMAP

(4).  配置SMTP服务器

(5).配置完成效果如下,(大家可以看到我们配置好的选项都被列出来了,我们得下载两个配置文件main.inc.php和db.inc.php并上传到时服务器中)

(6).上传至服务器相关目录中

[root@mail ~]# cd /var/www/html/webmail/config/
[root@mail config]# ll
total 92
-rw-r--r-- 1 root  root   2905 Jul 10 22:15 db.inc.php
-rw-r--r-- 1 vmail vmail  2893 Jun 16 23:10 db.inc.php.dist
-rw-r--r-- 1 root  root  38438 Jul 10 22:15 main.inc.php
-rw-r--r-- 1 vmail vmail 38414 Jun 16 23:10 main.inc.php.dist
-rw-r--r-- 1 vmail vmail  2731 Jun 16 23:10 mimetypes.php
[root@mail config]#

(7). 给WebMail授权

mysql> CREATE DATABASE roundcubemail;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON roundcubemail.* TO roundcubemail@localhost IDENTIFIED BY 'roundcubemail';
FLUSH PRIVILEGES;Query OK, 0 rows affected (0.01 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

10.单击CONTINUE继续

11.单击初始化数据库按钮

12.初始化完成并用phpmyadmin查看

可以看到已建立好的数据库文件!^_^……

13.下面我们进行WebMail测试

14.登录并进行收发邮件

可以看到发送成功,嘿嘿!下面我们用foxmail接收一下!

可以看到我们成功的收到了这封邮件测试成功!至些WebMail安装成功,下面我们就得说反垃圾邮件和邮件杀毒了,嘿嘿!

说明:由于整个mail邮件系统配置复杂,文字与图片较多我分了两篇进行说明!下一篇博文中CentOS6.4+LAMP+Postfix+Dovecot+Postfixadmin+Roundcubemail 打造企业级邮件服务器 (2)我们重点讲解,

十二、安装并配置病毒扫描与垃圾邮件过滤

十三、安装并配置managesieve插件

十四、常见问题分析

文章来源: http://blog.51cto.com/freeloda/1245492
发表在 mail | 标签为 | CentOS6.4+LAMP+Postfix+Dovecot+Postfixadmin+Roundcubemail (1)已关闭评论

市值榜-2017

2017中概股市值榜:

 

2017中国公司市值前50:

2017年全球公司市值排名TOP10

排名 公司名称 市值(亿美元)
1 苹果(Apple) 8150
2 Alphabet 6370
3 微软(Microsoft) 5580
4 Facebook(脸书) 4850
5 亚马逊(Amazon) 4610
6 伯克希尔·哈撒韦(BerkshireHathaway) 4380
7 阿里巴巴(Alibaba) 4150
8 腾讯(Tencent) 3940
9 强生(Johnson&Johnson) 3570
10 埃克森美孚(Exxon Mobil) 3230

 

 

 

 

发表在 digest | 市值榜-2017已关闭评论

文摘:Java各种反射性能对比

Java各种反射性能对比

对各种方法实现get方法的性能进行了一个测试。

总共有5个测试,,每个测试都是执行1亿次

1. 直接通过Java的get方法

2.通过高性能的ReflectAsm库进行测试

3.通过Java Class类自带的反射获得Method测试

4.使用Java自带的Property类获取Method测试

5.BeanUtils的getProperty测试

1 测试用Bean类

测试定义了如下一个bean类。

public class SimpleBean {
    private String name;
    public String getName() {
        return name;
    }
    public SimpleBean setName(String name) {
        this.name = name;
    }
}

注意定义要严格遵守JavaBean规范,否则在使用和反射相关工具时会出现NoSuchMethodException异常,或者导致性能非常差,JavaBean规范中最重要的几点如下:

1.类必须是public, 拥有public无参构造器,这样能够通过反射newInstance()动态构建对象.
         String className = ...;
         Class beanClass = Class.forName(className);
         Object beanInstance = beanClass.newInstance();
2.因为反射newInstance使用的是无参构造器, 所以对象实例化和配置是分开的
3.每一个property都有一个public的getter和setter方法, 命名方式是get/set+首字母大写的property名

经测试在SimpleBean为public时,1亿次调用method.invoke方法:

javaReflectGet 100000000 times using 218 ms

而SimpleBean为默认包可见时,1一亿次调用method.invoke方法:

javaReflectGet 100000000 times using 12955 ms

 

2.测试代码

public class TestIterator {
    private long times = 100_000_000L;
    private SimpleBean bean;
    private String formatter = "%s %d times using %d ms";
    @Before
    public void setUp() throws Exception {
        bean = new SimpleBean();
        bean.setName("haoyifen");
    }
    //直接通过Java的get方法
    @Test
    public void directGet() {
        Stopwatch watch = Stopwatch.createStarted();
        for (long i = 0; i < times; i++) {
            bean.getName();
        }
        watch.stop();
        String result = String.format(formatter, "directGet", times, watch.elapsed(TimeUnit.MILLISECONDS));
        System.out.println(result);
    }
    //通过高性能的ReflectAsm库进行测试,仅进行一次methodAccess获取
    @Test
    public void reflectAsmGet() {
        MethodAccess methodAccess = MethodAccess.get(SimpleBean.class);
        Stopwatch watch = Stopwatch.createStarted();
        for (long i = 0; i < times; i++) {
            methodAccess.invoke(bean, "getName");
        }
        watch.stop();
        String result = String.format(formatter, "reflectAsmGet", times, watch.elapsed(TimeUnit.MILLISECONDS));
        System.out.println(result);
    }
    //通过Java Class类自带的反射获得Method测试,仅进行一次method获取
    @Test
    public void javaReflectGet() throws IllegalAccessException, NoSuchMethodException, InvocationTargetException {
        Method getName = SimpleBean.class.getMethod("getName");
        Stopwatch watch = Stopwatch.createStarted();
        for (long i = 0; i < times; i++) {
            getName.invoke(bean);
        }
        watch.stop();
        String result = String.format(formatter, "javaReflectGet", times, watch.elapsed(TimeUnit.MILLISECONDS));
        System.out.println(result);
    }
    //使用Java自带的Property属性获取Method测试,仅进行一次method获取
    @Test
    public void propertyGet() throws IllegalAccessException, NoSuchMethodException, InvocationTargetException, IntrospectionException {
        Method method = null;
        BeanInfo beanInfo = Introspector.getBeanInfo(SimpleBean.class);
        PropertyDescriptor[] propertyDescriptors = beanInfo.getPropertyDescriptors();
        for (PropertyDescriptor propertyDescriptor : propertyDescriptors) {
            if (propertyDescriptor.getName().equals("name")) {
                method = propertyDescriptor.getReadMethod();
                break;
            }
        }
        Stopwatch watch = Stopwatch.createStarted();
        for (long i = 0; i < times; i++) {
           
            method.invoke(bean);
        }
        watch.stop();
        String result = String.format(formatter, "propertyGet", times, watch.elapsed(TimeUnit.MILLISECONDS));
        System.out.println(result);
    }
    //BeanUtils的getProperty测试
    @Test
    public void beanUtilsGet() throws IllegalAccessException, NoSuchMethodException, InvocationTargetException {
        Stopwatch watch = Stopwatch.createStarted();
        for (long i = 0; i < times; i++) {
            BeanUtils.getProperty(bean, "name");
        }
        watch.stop();
        String result = String.format(formatter, "beanUtilsGet", times, watch.elapsed(TimeUnit.MILLISECONDS));
        System.out.println(result);
    }
}

3.测试结果

在4核i5-4590@3.30GHz机器上跑以上测试,经过多次测量,基本在以下数值范围附近,测试数据如下:

1. directGet 100000000 times using 37 ms

2. reflectAsmGet 100000000 times using 39 ms

3. javaReflectGet 100000000 times using 222 ms

4. propertyGet 100000000 times using 335 ms

5. beanUtilsGet 100000000 times using 20066 ms

4.结果分析

1.使用reflectAsm库的性能能和直接调用get方法持平

2.Java自带的反射性能大致为直接get的1/6和1/9.

3.BeanUtils的getProperty非常的慢,为直接get性能的1/500,为Java自带反射性能的1/100和1/60.

 

为什么BeanUtils的getProperty方法性能这么慢?

...

摘自:https://www.cnblogs.com/Frank-Hao/p/5839096.html

参考:

https://blog.csdn.net/cike110120/article/details/51163668

https://blog.csdn.net/leixingbang1989/article/details/52035336

 

 

 

 

 

发表在 java | 文摘:Java各种反射性能对比已关闭评论

液晶屏尺寸

 

 

 

 

...

 

发表在 article | 液晶屏尺寸已关闭评论

shell启动java程序

 

#!/usr/bin/env bash
BASE_DIR=$(pwd)
LIB="${BASE_DIR}/lib/"
JAVA_OPTS=" -Xmx2048m -XX:PermSize=64m -XX:MaxPermSize=512m -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=1024k -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/mtdperf.hprof -server -Dfile.encoding=UTF-8"
START_CLASS="com.abc.cde.aaaserver"
nohup java ${JAVA_OPTS} -server -classpath "${LIB}/*:${LIB}/droolsRuntime/*:eiServer.jar" ${START_CLASS} &

如果用-jar,就不能用-cp(-classpath)

 

#!/bin/sh

BASE_DIR=$(pwd)
LIB="${BASE_DIR}/lib/"
JAVA_OPTS=" -Xmx2048m -XX:PermSize=64m -XX:MaxPermSize=512m -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=1024k -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/mtdperf.hprof -server -Dfile.encoding=UTF-8"
START_CLASS="com.tencent.bugly.EiServer"

echo ${LIB}

for libfile in ${LIB}/*.jar ; do
if [ -f $libfile ] ; then
    CLASSPATH=$libfile:${CLASSPATH}
fi
done

for libfile in ${BASE_DIR}/*.jar ; do
if [ -f $libfile ] ; then
    CLASSPATH=$libfile:${CLASSPATH}
fi
done

CLASSPATH=${BASE_DIR}:${CLASSPATH}
nohup "java" ${JAVA_OPTS} -server -cp ${CLASSPATH} ${START_CLASS} &

使用nohup是为了避免账户注销发送的hup信号,会导致该账户调用的程序注销,使用nohup会忽略此信号。

语句最后的&表示该进程在后台运行

 

前台启动JAR

java -jar XXX.jar

指定启动内存大小

java -Xms1024m -Xmx1024m -Xmn1024m -server -jar boot.jar

 

后台启动JAR

java -jar xxx.jar &

 

SpringBoot 制定控制台的标准输出

java -jar xxx.jar > catalina.out  2>&1 & 
  • catalina.out将标准输出指向制定文件catalina.out
  • 2>&1 输出所有的日志文件
  • & 后台启动

 

指定启端口:

java -jar demo.jar --server.port=9090

 

启动脚本

#!/bin/sh
#功能简介:启动上层目录下的jar文件
#参数简介:
#    $1:jar文件名(包含后缀名)
#    注意:jar文件必须位于startup.sh目录的上一层目录。

#启动参数
JAVA_OPTS="-server -Xms400m -Xmx400m -Xmn300m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xverify:none -XX:+DisableExplicitGC -Djava.awt.headless=true"

jar_name=$1
this_dir="$( cd "$( dirname "$0"  )" && pwd )"
parent_dir=`dirname "${this_dir}"`
log_dir="${parent_dir}/logs"
log_file="${log_dir}/catalina.out"
jar_file="${parent_dir}/userapps/${jar_name}"

#参数个数<1或者参数空值时,中断执行
if [ $# -lt 1 ] || [ -z $1 ]; then
    echo -e "\033[31m请输入要部署的jar包名称!\033[0m"
    exit 1
fi

#日志文件夹不存在,则创建
if [ ! -d "${log_dir}" ]; then
    mkdir "${log_dir}"
fi

#父目录下jar文件存在
if [ -f "${jar_file}" ]; then
    #启动jar包;重定向标准错误输出到文件,丢掉标准输出
    java $JAVA_OPTS -jar ${jar_file} 1>/dev/null 2>"${log_file}" &
    exit 0
else
    echo -e "\033[31m${jar_file}文件不存在!\033[0m"
    exit 1
fi

启动

./startup.sh xxx.jar

 

 

 

 

 

 

 

 

.

 

发表在 linux | shell启动java程序已关闭评论

Linux shell启动Java Main函数脚本

来源:https://blog.csdn.net/com15169113041/article/details/78191849

 

#!/bin/sh
#
#该脚本为Linux下启动java程序的通用脚本。即可以作为开机自启动service脚本被调用,
#也可以作为启动java程序的独立脚本来使用。
#
#Author: tudaxia.com, Date: 2011/6/7
#
#警告!!!:该脚本stop部分使用系统kill命令来强制终止指定的java程序进程。
#在杀死进程前,未作任何条件检查。在某些情况下,如程序正在进行文件或数据库写操作,
#可能会造成数据丢失或数据不完整。如果必须要考虑到这类情况,则需要改写此脚本,
#增加在执行kill命令前的一系列检查。
#
###################################
# 以下这些注释设置可以被chkconfig命令读取
# chkconfig: - 99 50
# description: Java程序启动脚本
# processname: test
# config: 如果需要的话,可以配置
###################################
#
###################################
#环境变量及程序执行参数
#需要根据实际环境以及Java程序名称来修改这些参数
###################################
#JDK所在路径
JAVA_HOME="/usr/java/jdk1.8.0_102"
#执行程序启动所使用的系统用户,考虑到安全,推荐不使用root帐号
#RUNNING_USER=portal
#Java程序所在的目录(classes的上一级目录)
APP_HOME=/opt/tmp/geecuser/geec_calculate
#需要启动的Java主程序(main方法类)
APP_MAINCLASS=com.ai.core.start.Main
#拼凑完整的classpath参数,包括指定lib目录下所有的jar
CLASSPATH=$APP_HOME/classes
for i in "$APP_HOME"/lib/*.jar; do
CLASSPATH="$CLASSPATH":"$i"
done

#java虚拟机启动参数
JAVA_OPTS="-ms1024m -mx1024m -Xmn512m -Djava.awt.headless=true -XX:MaxPermSize=256m"

###################################
#(函数)判断程序是否已启动
#
#说明:
#使用JDK自带的JPS命令及grep命令组合,准确查找pid
#jps 加 l 参数,表示显示java的完整包路径
#使用awk,分割出pid ($1部分),及Java程序名称($2部分)
###################################
#初始化psid变量(全局)
psid=0

checkpid() {
javaps=`$JAVA_HOME/bin/jps -l | grep $APP_MAINCLASS`

if [ -n "$javaps" ]; then
psid=`echo $javaps | awk '{print $1}'`
else
psid=0
fi
}

###################################
#(函数)启动程序
#
#说明:
#1. 首先调用checkpid函数,刷新$psid全局变量
#2. 如果程序已经启动($psid不等于0),则提示程序已启动
#3. 如果程序没有被启动,则执行启动命令行
#4. 启动命令执行后,再次调用checkpid函数
#5. 如果步骤4的结果能够确认程序的pid,则打印[OK],否则打印[Failed]
#注意:echo -n 表示打印字符后,不换行
#注意: "nohup 某命令 >/dev/null 2>&1 &" 的用法
###################################
start() {
checkpid

if [ $psid -ne 0 ]; then
echo "================================"
echo "warn: $APP_MAINCLASS already started! (pid=$psid)"
echo "================================"
else
echo -n "Starting $APP_MAINCLASS ..."
JAVA_CMD="nohup $JAVA_HOME/bin/java $JAVA_OPTS -classpath $CLASSPATH $APP_MAINCLASS >$APP_HOME/log/nohup 2>&1 &"
eval $JAVA_CMD
checkpid
if [ $psid -ne 0 ]; then
echo "(pid=$psid) [OK]"
else
echo "[Failed]"
fi
fi
}

###################################
#(函数)停止程序
#
#说明:
#1. 首先调用checkpid函数,刷新$psid全局变量
#2. 如果程序已经启动($psid不等于0),则开始执行停止,否则,提示程序未运行
#3. 使用kill -9 pid命令进行强制杀死进程
#4. 执行kill命令行紧接其后,马上查看上一句命令的返回值: $?
#5. 如果步骤4的结果$?等于0,则打印[OK],否则打印[Failed]
#6. 为了防止java程序被启动多次,这里增加反复检查进程,反复杀死的处理(递归调用stop)。
#注意:echo -n 表示打印字符后,不换行
#注意: 在shell编程中,"$?" 表示上一句命令或者一个函数的返回值
###################################
stop() {
checkpid

if [ $psid -ne 0 ]; then
echo -n "Stopping $APP_MAINCLASS ...(pid=$psid) "
kill -9 $psid
if [ $? -eq 0 ]; then
echo "[OK]"
else
echo "[Failed]"
fi

checkpid
if [ $psid -ne 0 ]; then
stop
fi
else
echo "================================"
echo "warn: $APP_MAINCLASS is not running"
echo "================================"
fi
}

###################################
#(函数)检查程序运行状态
#
#说明:
#1. 首先调用checkpid函数,刷新$psid全局变量
#2. 如果程序已经启动($psid不等于0),则提示正在运行并表示出pid
#3. 否则,提示程序未运行
###################################
status() {
checkpid

if [ $psid -ne 0 ]; then
echo "$APP_MAINCLASS is running! (pid=$psid)"
else
echo "$APP_MAINCLASS is not running"
fi
}

###################################
#(函数)打印系统环境参数
###################################
info() {
echo "System Information:"
echo "****************************"
echo `head -n 1 /etc/issue`
echo `uname -a`
echo
echo "JAVA_HOME=$JAVA_HOME"
echo `$JAVA_HOME/bin/java -version`
echo
echo "APP_HOME=$APP_HOME"
echo "APP_MAINCLASS=$APP_MAINCLASS"
echo "****************************"
}

###################################
#读取脚本的第一个参数($1),进行判断
#参数取值范围:{start|stop|restart|status|info}
#如参数不在指定范围之内,则打印帮助信息
###################################
case "$1" in
'start')
start
;;
'stop')
stop
;;
'restart')
stop
start
;;
'status')
status
;;
'info')
info
;;
*)
echo "Usage: $0 {start|stop|restart|status|info}"
exit 1
esac
exit 0

 

 

 

.

 

 

发表在 linux | Linux shell启动Java Main函数脚本已关闭评论

Raft一致性算法论文的中文翻译

寻找一种易于理解的一致性算法(扩展版)

摘要

Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能,但是它的算法结构和 Paxos 不同,使得 Raft 算法更加容易理解并且更容易构建实际的系统。为了提升可理解性,Raft 将一致性算法分解成了几个关键模块,例如领导人选举、日志复制和安全性。同时它通过实施一个更强的一致性来减少需要考虑的状态的数量。从一个用户研究的结果可以证明,对于学生而言,Raft 算法比 Paxos 算法更加容易学习。Raft 算法还包括一个新的机制来允许集群成员的动态改变,它利用重叠的大多数来保证安全性。

1 介绍

一致性算法允许一组机器像一个整体一样工作,即使其中一些机器出现故障也能够继续工作下去。正因为如此,一致性算法在构建可信赖的大规模软件系统中扮演着重要的角色。在过去的 10 年里,Paxos 算法统治着一致性算法这一领域:绝大多数的实现都是基于 Paxos 或者受其影响。同时 Paxos 也成为了教学领域里讲解一致性问题时的示例。

但是不幸的是,尽管有很多工作都在尝试降低它的复杂性,但是 Paxos 算法依然十分难以理解。并且,Paxos 自身的算法结构需要进行大幅的修改才能够应用到实际的系统中。这些都导致了工业界和学术界都对 Paxos 算法感到十分头疼。

和 Paxos 算法进行过努力之后,我们开始寻找一种新的一致性算法,可以为构建实际的系统和教学提供更好的基础。我们的做法是不寻常的,我们的首要目标是可理解性:我们是否可以在实际系统中定义一个一致性算法,并且能够比 Paxos 算法以一种更加容易的方式来学习。此外,我们希望该算法方便系统构建者的直觉的发展。不仅一个算法能够工作很重要,而且能够显而易见的知道为什么能工作也很重要。

Raft 一致性算法就是这些工作的结果。在设计 Raft 算法的时候,我们使用一些特别的技巧来提升它的可理解性,包括算法分解(Raft 主要被分成了领导人选举,日志复制和安全三个模块)和减少状态机的状态(相对于 Paxos,Raft 减少了非确定性和服务器互相处于非一致性的方式)。一份针对两所大学 43 个学生的研究表明 Raft 明显比 Paxos 算法更加容易理解。在这些学生同时学习了这两种算法之后,和 Paxos 比起来,其中 33 个学生能够回答有关于 Raft 的问题。

Raft 算法在许多方面和现有的一致性算法都很相似(主要是 Oki 和 Liskov 的 Viewstamped Replication),但是它也有一些独特的特性:

  • 强领导者:和其他一致性算法相比,Raft 使用一种更强的领导能力形式。比如,日志条目只从领导者发送给其他的服务器。这种方式简化了对复制日志的管理并且使得 Raft 算法更加易于理解。
  • 领导选举:Raft 算法使用一个随机计时器来选举领导者。这种方式只是在任何一致性算法都必须实现的心跳机制上增加了一点机制。在解决冲突的时候会更加简单快捷。
  • 成员关系调整:Raft 使用一种共同一致的方法来处理集群成员变换的问题,在这种方法下,处于调整过程中的两种不同的配置集群中大多数机器会有重叠,这就使得集群在成员变换的时候依然可以继续工作。

我们相信,Raft 算法不论出于教学目的还是作为实践项目的基础都是要比 Paxos 或者其他一致性算法要优异的。它比其他算法更加简单,更加容易理解;它的算法描述足以实现一个现实的系统;它有好多开源的实现并且在很多公司里使用;它的安全性已经被证明;它的效率和其他算法比起来也不相上下。

接下来,这篇论文会介绍以下内容:复制状态机问题(第 2 节),讨论 Paxos 的优点和缺点(第 3 节),讨论我们为了理解能力而使用的方法(第 4 节),阐述 Raft 一致性算法(第 5-8 节),评价 Raft 算法(第 9 节),以及一些相关的工作(第 10 节)。

2 复制状态机

一致性算法是从复制状态机的背景下提出的(参考英文原文引用37)。在这种方法中,一组服务器上的状态机产生相同状态的副本,并且在一些机器宕掉的情况下也可以继续运行。复制状态机在分布式系统中被用于解决很多容错的问题。例如,大规模的系统中通常都有一个集群领导者,像 GFS、HDFS 和 RAMCloud,典型应用就是一个独立的的复制状态机去管理领导选举和存储配置信息并且在领导人宕机的情况下也要存活下来。比如 Chubby 和 ZooKeeper。

 

图 1 :复制状态机的结构。一致性算法管理着来自客户端指令的复制日志。状态机从日志中处理相同顺序的相同指令,所以产生的结果也是相同的。

复制状态机通常都是基于复制日志实现的,如图 1。每一个服务器存储一个包含一系列指令的日志,并且按照日志的顺序进行执行。每一个日志都按照相同的顺序包含相同的指令,所以每一个服务器都执行相同的指令序列。因为每个状态机都是确定的,每一次执行操作都产生相同的状态和同样的序列。

保证复制日志相同就是一致性算法的工作了。在一台服务器上,一致性模块接收客户端发送来的指令然后增加到自己的日志中去。它和其他服务器上的一致性模块进行通信来保证每一个服务器上的日志最终都以相同的顺序包含相同的请求,尽管有些服务器会宕机。一旦指令被正确的复制,每一个服务器的状态机按照日志顺序处理他们,然后输出结果被返回给客户端。因此,服务器集群看起来形成一个高可靠的状态机。

实际系统中使用的一致性算法通常含有以下特性:

  • 安全性保证(绝对不会返回一个错误的结果):在非拜占庭错误情况下,包括网络延迟、分区、丢包、冗余和乱序等错误都可以保证正确。
  • 可用性:集群中只要有大多数的机器可运行并且能够相互通信、和客户端通信,就可以保证可用。因此,一个典型的包含 5 个节点的集群可以容忍两个节点的失败。服务器被停止就认为是失败。他们当有稳定的存储的时候可以从状态中恢复回来并重新加入集群。
  • 不依赖时序来保证一致性:物理时钟错误或者极端的消息延迟在可能只有在最坏情况下才会导致可用性问题。
  • 通常情况下,一条指令可以尽可能快的在集群中大多数节点响应一轮远程过程调用时完成。小部分比较慢的节点不会影响系统整体的性能。

3 Paxos算法的问题

在过去的 10 年里,Leslie Lamport 的 Paxos 算法几乎已经成为一致性的代名词:Paxos 是在课程教学中最经常使用的算法,同时也是大多数一致性算法实现的起点。Paxos 首先定义了一个能够达成单一决策一致的协议,比如单条的复制日志项。我们把这一子集叫做单决策 Paxos。然后通过组合多个 Paxos 协议的实例来促进一系列决策的达成。Paxos 保证安全性和活性,同时也支持集群成员关系的变更。Paxos 的正确性已经被证明,在通常情况下也很高效。

不幸的是,Paxos 有两个明显的缺点。第一个缺点是 Paxos 算法特别的难以理解。完整的解释是出了名的不透明;通过极大的努力之后,也只有少数人成功理解了这个算法。因此,有了几次用更简单的术语来解释 Paxos 的尝试。尽管这些解释都只关注了单决策的子集问题,但依然很具有挑战性。在 2012 年 NSDI 的会议中的一次调查显示,很少有人对 Paxos 算法感到满意,甚至在经验老道的研究者中也是如此。我们自己也尝试去理解 Paxos;我们一直没能理解 Paxos 直到我们读了很多对 Paxos 的简化解释并且设计了我们自己的算法之后,这一过程花了近一年时间。

我们假设 Paxos 的不透明性来自它选择单决策问题作为它的基础。单决策 Paxos 是晦涩微妙的,它被划分成了两种没有简单直观解释和无法独立理解的情景。因此,这导致了很难建立起直观的感受为什么单决策 Paxos 算法能够工作。构成多决策 Paxos 增加了很多错综复杂的规则。我们相信,在多决策上达成一致性的问题(一份日志而不是单一的日志记录)能够被分解成其他的方式并且更加直接和明显。

Paxos算法的第二个问题就是它没有提供一个足够好的用来构建一个现实系统的基础。一个原因是还没有一种被广泛认同的多决策问题的算法。Lamport 的描述基本上都是关于单决策 Paxos 的;他简要描述了实施多决策 Paxos 的方法,但是缺乏很多细节。当然也有很多具体化 Paxos 的尝试,但是他们都互相不一样,和 Paxos 的概述也不同。例如 Chubby 这样的系统实现了一个类似于 Paxos 的算法,但是大多数的细节并没有被公开。

而且,Paxos 算法的结构也不是十分易于构建实践的系统;单决策分解也会产生其他的结果。例如,独立的选择一组日志条目然后合并成一个序列化的日志并没有带来太多的好处,仅仅增加了不少复杂性。围绕着日志来设计一个系统是更加简单高效的;新日志条目以严格限制的顺序增添到日志中去。另一个问题是,Paxos 使用了一种对等的点对点的方式作为它的核心(尽管它最终提议了一种弱领导人的方法来优化性能)。在只有一个决策会被制定的简化世界中是很有意义的,但是很少有现实的系统使用这种方式。如果有一系列的决策需要被制定,首先选择一个领导人,然后让他去协调所有的决议,会更加简单快速。

因此,实际的系统中很少有和 Paxos 相似的实践。每一种实现都是从 Paxos 开始研究,然后发现很多实现上的难题,再然后开发了一种和 Paxos 明显不一样的结构。这样是非常费时和容易出错的,并且理解 Paxos 的难度使得这个问题更加糟糕。Paxos 算法在理论上被证明是正确可行的,但是现实的系统和 Paxos 差别是如此的大,以至于这些证明没有什么太大的价值。下面来自 Chubby 实现非常典型:

在Paxos算法描述和实现现实系统中间有着巨大的鸿沟。最终的系统建立在一种没有经过证明的算法之上。

由于以上问题,我们认为 Paxos 算法既没有提供一个良好的基础给实践的系统,也没有给教学很好的帮助。基于一致性问题在大规模软件系统中的重要性,我们决定看看我们是否可以设计一个拥有更好特性的替代 Paxos 的一致性算法。Raft算法就是这次实验的结果。

4 为了可理解性的设计

设计 Raft 算法我们有几个初衷:它必须提供一个完整的实际的系统实现基础,这样才能大大减少开发者的工作;它必须在任何情况下都是安全的并且在大多数的情况下都是可用的;并且它的大部分操作必须是高效的。但是我们最重要也是最大的挑战是可理解性。它必须保证对于普遍的人群都可以十分容易的去理解。另外,它必须能够让人形成直观的认识,这样系统的构建者才能够在现实中进行必然的扩展。

在设计 Raft 算法的时候,有很多的点需要我们在各种备选方案中进行选择。在这种情况下,我们评估备选方案基于可理解性原则:解释各个备选方案有多大的难度(例如,Raft 的状态空间有多复杂,是否有微妙的暗示)?对于一个读者而言,完全理解这个方案和暗示是否容易?

我们意识到对这种可理解性分析上具有高度的主观性;尽管如此,我们使用了两种通常适用的技术来解决这个问题。第一个技术就是众所周知的问题分解:只要有可能,我们就将问题分解成几个相对独立的,可被解决的、可解释的和可理解的子问题。例如,Raft 算法被我们分成领导人选举,日志复制,安全性和角色改变几个部分。

我们使用的第二个方法是通过减少状态的数量来简化需要考虑的状态空间,使得系统更加连贯并且在可能的时候消除不确定性。特别的,所有的日志是不允许有空洞的,并且 Raft 限制了日志之间变成不一致状态的可能。尽管在大多数情况下我们都试图去消除不确定性,但是也有一些情况下不确定性可以提升可理解性。尤其是,随机化方法增加了不确定性,但是他们有利于减少状态空间数量,通过处理所有可能选择时使用相似的方法。我们使用随机化去简化 Raft 中领导人选举算法。

5 Raft 一致性算法

Raft 是一种用来管理章节 2 中描述的复制日志的算法。图 2 为了参考之用,总结这个算法的简略版本,图 3 列举了这个算法的一些关键特性。图中的这些元素会在剩下的章节逐一介绍。

Raft 通过选举一个高贵的领导人,然后给予他全部的管理复制日志的责任来实现一致性。领导人从客户端接收日志条目,把日志条目复制到其他服务器上,并且当保证安全性的时候告诉其他的服务器应用日志条目到他们的状态机中。拥有一个领导人大大简化了对复制日志的管理。例如,领导人可以决定新的日志条目需要放在日志中的什么位置而不需要和其他服务器商议,并且数据都从领导人流向其他服务器。一个领导人可以宕机,可以和其他服务器失去连接,这时一个新的领导人会被选举出来。

通过领导人的方式,Raft 将一致性问题分解成了三个相对独立的子问题,这些问题会在接下来的子章节中进行讨论:

  • 领导选举:一个新的领导人需要被选举出来,当现存的领导人宕机的时候(章节 5.2)
  • 日志复制:领导人必须从客户端接收日志然后复制到集群中的其他节点,并且强制要求其他节点的日志保持和自己相同。
  • 安全性:在 Raft 中安全性的关键是在图 3 中展示的状态机安全:如果有任何的服务器节点已经应用了一个确定的日志条目到它的状态机中,那么其他服务器节点不能在同一个日志索引位置应用一个不同的指令。章节 5.4 阐述了 Raft 算法是如何保证这个特性的;这个解决方案涉及到一个额外的选举机制(5.2 节)上的限制。

在展示一致性算法之后,这一章节会讨论可用性的一些问题和系统中的候选人角色的问题。

状态

状态 所有服务器上持久存在的
currentTerm 服务器最后一次知道的任期号(初始化为 0,持续递增)
votedFor 在当前获得选票的候选人的 Id
log[] 日志条目集;每一个条目包含一个用户状态机执行的指令,和收到时的任期号
状态 所有服务器上经常变的
commitIndex 已知的最大的已经被提交的日志条目的索引值
lastApplied 最后被应用到状态机的日志条目索引值(初始化为 0,持续递增)
状态 在领导人里经常改变的 (选举后重新初始化)
nextIndex[] 对于每一个服务器,需要发送给他的下一个日志条目的索引值(初始化为领导人最后索引值加一)
matchIndex[] 对于每一个服务器,已经复制给他的日志的最高索引值

附加日志 RPC

由领导人负责调用来复制日志指令;也会用作heartbeat

参数 解释
term 领导人的任期号
leaderId 领导人的 Id,以便于跟随者重定向请求
prevLogIndex 新的日志条目紧随之前的索引值
prevLogTerm prevLogIndex 条目的任期号
entries[] 准备存储的日志条目(表示心跳时为空;一次性发送多个是为了提高效率)
leaderCommit 领导人已经提交的日志的索引值
返回值 解释
term 当前的任期号,用于领导人去更新自己
success 跟随者包含了匹配上 prevLogIndex 和 prevLogTerm 的日志时为真

接收者实现:

  1. 如果 term < currentTerm 就返回 false (5.1 节)
  2. 如果日志在 prevLogIndex 位置处的日志条目的任期号和 prevLogTerm 不匹配,则返回 false (5.3 节)
  3. 如果已经存在的日志条目和新的产生冲突(索引值相同但是任期号不同),删除这一条和之后所有的 (5.3 节)
  4. 附加任何在已有的日志中不存在的条目
  5. 如果 leaderCommit > commitIndex,令 commitIndex 等于 leaderCommit 和 新日志条目索引值中较小的一个

请求投票 RPC

由候选人负责调用用来征集选票(5.2 节)

参数 解释
term 候选人的任期号
candidateId 请求选票的候选人的 Id
lastLogIndex 候选人的最后日志条目的索引值
lastLogTerm 候选人最后日志条目的任期号
返回值 解释
term 当前任期号,以便于候选人去更新自己的任期号
voteGranted 候选人赢得了此张选票时为真

接收者实现:

  1. 如果term < currentTerm返回 false (5.2 节)
  2. 如果 votedFor 为空或者就是 candidateId,并且候选人的日志至少和自己一样新,那么就投票给他(5.2 节,5.4 节)

所有服务器需遵守的规则

所有服务器:

  • 如果commitIndex > lastApplied,那么就 lastApplied 加一,并把log[lastApplied]应用到状态机中(5.3 节)
  • 如果接收到的 RPC 请求或响应中,任期号T > currentTerm,那么就令 currentTerm 等于 T,并切换状态为跟随者(5.1 节)

跟随者(5.2 节):

  • 响应来自候选人和领导者的请求
  • 如果在超过选举超时时间的情况之前都没有收到领导人的心跳,或者是候选人请求投票的,就自己变成候选人

候选人(5.2 节):

  • 在转变成候选人后就立即开始选举过程
    • 自增当前的任期号(currentTerm)
    • 给自己投票
    • 重置选举超时计时器
    • 发送请求投票的 RPC 给其他所有服务器
  • 如果接收到大多数服务器的选票,那么就变成领导人
  • 如果接收到来自新的领导人的附加日志 RPC,转变成跟随者
  • 如果选举过程超时,再次发起一轮选举

领导人:

  • 一旦成为领导人:发送空的附加日志 RPC(心跳)给其他所有的服务器;在一定的空余时间之后不停的重复发送,以阻止跟随者超时(5.2 节)
  • 如果接收到来自客户端的请求:附加条目到本地日志中,在条目被应用到状态机后响应客户端(5.3 节)
  • 如果对于一个跟随者,最后日志条目的索引值大于等于 nextIndex,那么:发送从 nextIndex 开始的所有日志条目:
    • 如果成功:更新相应跟随者的 nextIndex 和 matchIndex
    • 如果因为日志不一致而失败,减少 nextIndex 重试
  • 如果存在一个满足N > commitIndex的 N,并且大多数的matchIndex[i] ≥ N成立,并且log[N].term == currentTerm成立,那么令 commitIndex 等于这个 N (5.3 和 5.4 节)

图 2:一个关于 Raft 一致性算法的浓缩总结(不包括成员变换和日志压缩)。

特性 解释
选举安全特性 对于一个给定的任期号,最多只会有一个领导人被选举出来(5.2 节)
领导人只附加原则 领导人绝对不会删除或者覆盖自己的日志,只会增加(5.3 节)
日志匹配原则 如果两个日志在相同的索引位置的日志条目的任期号相同,那么我们就认为这个日志从头到这个索引位置之间全部完全相同(5.3 节)
领导人完全特性 如果某个日志条目在某个任期号中已经被提交,那么这个条目必然出现在更大任期号的所有领导人中(5.4 节)
状态机安全特性 如果一个领导人已经在给定的索引值位置的日志条目应用到状态机中,那么其他任何的服务器在这个索引位置不会提交一个不同的日志(5.4.3 节)

图 3:Raft 在任何时候都保证以上的各个特性。

5.1 Raft 基础

一个 Raft 集群包含若干个服务器节点;通常是 5 个,这允许整个系统容忍 2 个节点的失效。在任何时刻,每一个服务器节点都处于这三个状态之一:领导人、跟随者或者候选人。在通常情况下,系统中只有一个领导人并且其他的节点全部都是跟随者。跟随者都是被动的:他们不会发送任何请求,只是简单的响应来自领导者或者候选人的请求。领导人处理所有的客户端请求(如果一个客户端和跟随者联系,那么跟随者会把请求重定向给领导人)。第三种状态,候选人,是用来在 5.2 节描述的选举新领导人时使用。图 4 展示了这些状态和他们之间的转换关系;这些转换关系会在接下来进行讨论。

图 4:服务器状态。跟随者只响应来自其他服务器的请求。如果跟随者接收不到消息,那么他就会变成候选人并发起一次选举。获得集群中大多数选票的候选人将成为领导者。在一个任期内,领导人一直都会是领导人直到自己宕机了。

图 5:时间被划分成一个个的任期,每个任期开始都是一次选举。在选举成功后,领导人会管理整个集群直到任期结束。有时候选举会失败,那么这个任期就会没有领导人而结束。任期之间的切换可以在不同的时间不同的服务器上观察到。

Raft 把时间分割成任意长度的任期,如图 5。任期用连续的整数标记。每一段任期从一次选举开始,就像章节 5.2 描述的一样,一个或者多个候选人尝试成为领导者。如果一个候选人赢得选举,然后他就在接下来的任期内充当领导人的职责。在某些情况下,一次选举过程会造成选票的瓜分。在这种情况下,这一任期会以没有领导人结束;一个新的任期(和一次新的选举)会很快重新开始。Raft 保证了在一个给定的任期内,最多只有一个领导者。

不同的服务器节点可能多次观察到任期之间的转换,但在某些情况下,一个节点也可能观察不到任何一次选举或者整个任期全程。任期在 Raft 算法中充当逻辑时钟的作用,这会允许服务器节点查明一些过期的信息比如陈旧的领导者。每一个节点存储一个当前任期号,这一编号在整个时期内单调的增长。当服务器之间通信的时候会交换当前任期号;如果一个服务器的当前任期号比其他人小,那么他会更新自己的编号到较大的编号值。如果一个候选人或者领导者发现自己的任期号过期了,那么他会立即恢复成跟随者状态。如果一个节点接收到一个包含过期的任期号的请求,那么他会直接拒绝这个请求。

Raft 算法中服务器节点之间通信使用远程过程调用(RPCs),并且基本的一致性算法只需要两种类型的 RPCs。请求投票(RequestVote) RPCs 由候选人在选举期间发起(章节 5.2),然后附加条目(AppendEntries)RPCs 由领导人发起,用来复制日志和提供一种心跳机制(章节 5.3)。第 7 节为了在服务器之间传输快照增加了第三种 RPC。当服务器没有及时的收到 RPC 的响应时,会进行重试, 并且他们能够并行的发起 RPCs 来获得最佳的性能。

5.2 领导人选举

Raft 使用一种心跳机制来触发领导人选举。当服务器程序启动时,他们都是跟随者身份。一个服务器节点继续保持着跟随者状态只要他从领导人或者候选者处接收到有效的 RPCs。领导者周期性的向所有跟随者发送心跳包(即不包含日志项内容的附加日志项 RPCs)来维持自己的权威。如果一个跟随者在一段时间里没有接收到任何消息,也就是选举超时,那么他就会认为系统中没有可用的领导者,并且发起选举以选出新的领导者。

要开始一次选举过程,跟随者先要增加自己的当前任期号并且转换到候选人状态。然后他会并行的向集群中的其他服务器节点发送请求投票的 RPCs 来给自己投票。候选人会继续保持着当前状态直到以下三件事情之一发生:(a) 他自己赢得了这次的选举,(b) 其他的服务器成为领导者,(c) 一段时间之后没有任何一个获胜的人。这些结果会分别的在下面的段落里进行讨论。

当一个候选人从整个集群的大多数服务器节点获得了针对同一个任期号的选票,那么他就赢得了这次选举并成为领导人。每一个服务器最多会对一个任期号投出一张选票,按照先来先服务的原则(注意:5.4 节在投票上增加了一点额外的限制)。要求大多数选票的规则确保了最多只会有一个候选人赢得此次选举(图 3 中的选举安全性)。一旦候选人赢得选举,他就立即成为领导人。然后他会向其他的服务器发送心跳消息来建立自己的权威并且阻止新的领导人的产生。

在等待投票的时候,候选人可能会从其他的服务器接收到声明它是领导人的附加日志项 RPC。如果这个领导人的任期号(包含在此次的 RPC中)不小于候选人当前的任期号,那么候选人会承认领导人合法并回到跟随者状态。 如果此次 RPC 中的任期号比自己小,那么候选人就会拒绝这次的 RPC 并且继续保持候选人状态。

第三种可能的结果是候选人既没有赢得选举也没有输:如果有多个跟随者同时成为候选人,那么选票可能会被瓜分以至于没有候选人可以赢得大多数人的支持。当这种情况发生的时候,每一个候选人都会超时,然后通过增加当前任期号来开始一轮新的选举。然而,没有其他机制的话,选票可能会被无限的重复瓜分。

Raft 算法使用随机选举超时时间的方法来确保很少会发生选票瓜分的情况,就算发生也能很快的解决。为了阻止选票起初就被瓜分,选举超时时间是从一个固定的区间(例如 150-300 毫秒)随机选择。这样可以把服务器都分散开以至于在大多数情况下只有一个服务器会选举超时;然后他赢得选举并在其他服务器超时之前发送心跳包。同样的机制被用在选票瓜分的情况下。每一个候选人在开始一次选举的时候会重置一个随机的选举超时时间,然后在超时时间内等待投票的结果;这样减少了在新的选举中另外的选票瓜分的可能性。9.3 节展示了这种方案能够快速的选出一个领导人。

领导人选举这个例子,体现了可理解性原则是如何指导我们进行方案设计的。起初我们计划使用一种排名系统:每一个候选人都被赋予一个唯一的排名,供候选人之间竞争时进行选择。如果一个候选人发现另一个候选人拥有更高的排名,那么他就会回到跟随者状态,这样高排名的候选人能够更加容易的赢得下一次选举。但是我们发现这种方法在可用性方面会有一点问题(如果高排名的服务器宕机了,那么低排名的服务器可能会超时并再次进入候选人状态。而且如果这个行为发生得足够快,则可能会导致整个选举过程都被重置掉)。我们针对算法进行了多次调整,但是每次调整之后都会有新的问题。最终我们认为随机重试的方法是更加明显和易于理解的。

5.3 日志复制

一旦一个领导人被选举出来,他就开始为客户端提供服务。客户端的每一个请求都包含一条被复制状态机执行的指令。领导人把这条指令作为一条新的日志条目附加到日志中去,然后并行的发起附加条目 RPCs 给其他的服务器,让他们复制这条日志条目。当这条日志条目被安全的复制(下面会介绍),领导人会应用这条日志条目到它的状态机中然后把执行的结果返回给客户端。如果跟随者崩溃或者运行缓慢,再或者网络丢包,领导人会不断的重复尝试附加日志条目 RPCs (尽管已经回复了客户端)直到所有的跟随者都最终存储了所有的日志条目。

图 6:日志由有序序号标记的条目组成。每个条目都包含创建时的任期号(图中框中的数字),和一个状态机需要执行的指令。一个条目当可以安全的被应用到状态机中去的时候,就认为是可以提交了。

日志以图 6 展示的方式组织。每一个日志条目存储一条状态机指令和从领导人收到这条指令时的任期号。日志中的任期号用来检查是否出现不一致的情况,同时也用来保证图 3 中的某些性质。每一条日志条目同时也都有一个整数索引值来表明它在日志中的位置。

领导人来决定什么时候把日志条目应用到状态机中是安全的;这种日志条目被称为已提交。Raft 算法保证所有已提交的日志条目都是持久化的并且最终会被所有可用的状态机执行。在领导人将创建的日志条目复制到大多数的服务器上的时候,日志条目就会被提交(例如在图 6 中的条目 7)。同时,领导人的日志中之前的所有日志条目也都会被提交,包括由其他领导人创建的条目。5.4 节会讨论某些当在领导人改变之后应用这条规则的隐晦内容,同时他也展示了这种提交的定义是安全的。领导人跟踪了最大的将会被提交的日志项的索引,并且索引值会被包含在未来的所有附加日志 RPCs (包括心跳包),这样其他的服务器才能最终知道领导人的提交位置。一旦跟随者知道一条日志条目已经被提交,那么他也会将这个日志条目应用到本地的状态机中(按照日志的顺序)。

我们设计了 Raft 的日志机制来维护一个不同服务器的日志之间的高层次的一致性。这么做不仅简化了系统的行为也使得更加可预计,同时他也是安全性保证的一个重要组件。Raft 维护着以下的特性,这些同时也组成了图 3 中的日志匹配特性:

  • 如果在不同的日志中的两个条目拥有相同的索引和任期号,那么他们存储了相同的指令。
  • 如果在不同的日志中的两个条目拥有相同的索引和任期号,那么他们之前的所有日志条目也全部相同。

第一个特性来自这样的一个事实,领导人最多在一个任期里在指定的一个日志索引位置创建一条日志条目,同时日志条目在日志中的位置也从来不会改变。第二个特性由附加日志 RPC 的一个简单的一致性检查所保证。在发送附加日志 RPC 的时候,领导人会把新的日志条目紧接着之前的条目的索引位置和任期号包含在里面。如果跟随者在它的日志中找不到包含相同索引位置和任期号的条目,那么他就会拒绝接收新的日志条目。一致性检查就像一个归纳步骤:一开始空的日志状态肯定是满足日志匹配特性的,然后一致性检查保护了日志匹配特性当日志扩展的时候。因此,每当附加日志 RPC 返回成功时,领导人就知道跟随者的日志一定是和自己相同的了。

在正常的操作中,领导人和跟随者的日志保持一致性,所以附加日志 RPC 的一致性检查从来不会失败。然而,领导人崩溃的情况会使得日志处于不一致的状态(老的领导人可能还没有完全复制所有的日志条目)。这种不一致问题会在领导人和跟随者的一系列崩溃下加剧。图 7 展示了跟随者的日志可能和新的领导人不同的方式。跟随者可能会丢失一些在新的领导人中有的日志条目,他也可能拥有一些领导人没有的日志条目,或者两者都发生。丢失或者多出日志条目可能会持续多个任期。

图 7:当一个领导人成功当选时,跟随者可能是任何情况(a-f)。每一个盒子表示是一个日志条目;里面的数字表示任期号。跟随者可能会缺少一些日志条目(a-b),可能会有一些未被提交的日志条目(c-d),或者两种情况都存在(e-f)。例如,场景 f 可能会这样发生,某服务器在任期 2 的时候是领导人,已附加了一些日志条目到自己的日志中,但在提交之前就崩溃了;很快这个机器就被重启了,在任期 3 重新被选为领导人,并且又增加了一些日志条目到自己的日志中;在任期 2 和任期 3 的日志被提交之前,这个服务器又宕机了,并且在接下来的几个任期里一直处于宕机状态。

在 Raft 算法中,领导人处理不一致是通过强制跟随者直接复制自己的日志来解决了。这意味着在跟随者中的冲突的日志条目会被领导人的日志覆盖。5.4 节会阐述如何通过增加一些限制来使得这样的操作是安全的。

要使得跟随者的日志进入和自己一致的状态,领导人必须找到最后两者达成一致的地方,然后删除从那个点之后的所有日志条目,发送自己的日志给跟随者。所有的这些操作都在进行附加日志 RPCs 的一致性检查时完成。领导人针对每一个跟随者维护了一个 nextIndex,这表示下一个需要发送给跟随者的日志条目的索引地址。当一个领导人刚获得权力的时候,他初始化所有的 nextIndex 值为自己的最后一条日志的index加1(图 7 中的 11)。如果一个跟随者的日志和领导人不一致,那么在下一次的附加日志 RPC 时的一致性检查就会失败。在被跟随者拒绝之后,领导人就会减小 nextIndex 值并进行重试。最终 nextIndex 会在某个位置使得领导人和跟随者的日志达成一致。当这种情况发生,附加日志 RPC 就会成功,这时就会把跟随者冲突的日志条目全部删除并且加上领导人的日志。一旦附加日志 RPC 成功,那么跟随者的日志就会和领导人保持一致,并且在接下来的任期里一直继续保持。

如果需要的话,算法可以通过减少被拒绝的附加日志 RPCs 的次数来优化。例如,当附加日志 RPC 的请求被拒绝的时候,跟随者可以包含冲突的条目的任期号和自己存储的那个任期的最早的索引地址。借助这些信息,领导人可以减小 nextIndex 越过所有那个任期冲突的所有日志条目;这样就变成每个任期需要一次附加条目 RPC 而不是每个条目一次。在实践中,我们十分怀疑这种优化是否是必要的,因为失败是很少发生的并且也不大可能会有这么多不一致的日志。

通过这种机制,领导人在获得权力的时候就不需要任何特殊的操作来恢复一致性。他只需要进行正常的操作,然后日志就能自动的在回复附加日志 RPC 的一致性检查失败的时候自动趋于一致。领导人从来不会覆盖或者删除自己的日志(图 3 的领导人只附加特性)。

日志复制机制展示出了第 2 节中形容的一致性特性:Raft 能够接受,复制并应用新的日志条目只要大部分的机器是工作的;在通常的情况下,新的日志条目可以在一次 RPC 中被复制给集群中的大多数机器;并且单个的缓慢的跟随者不会影响整体的性能。

5.4 安全性

前面的章节里描述了 Raft 算法是如何选举和复制日志的。然而,到目前为止描述的机制并不能充分的保证每一个状态机会按照相同的顺序执行相同的指令。例如,一个跟随者可能会进入不可用状态同时领导人已经提交了若干的日志条目,然后这个跟随者可能会被选举为领导人并且覆盖这些日志条目;因此,不同的状态机可能会执行不同的指令序列。

这一节通过在领导选举的时候增加一些限制来完善 Raft 算法。这一限制保证了任何的领导人对于给定的任期号,都拥有了之前任期的所有被提交的日志条目(图 3 中的领导人完整特性)。增加这一选举时的限制,我们对于提交时的规则也更加清晰。最终,我们将展示对于领导人完整特性的简要证明,并且说明领导人是如何领导复制状态机的做出正确行为的。

5.4.1 选举限制

在任何基于领导人的一致性算法中,领导人都必须存储所有已经提交的日志条目。在某些一致性算法中,例如 Viewstamped Replication,某个节点即使是一开始并没有包含所有已经提交的日志条目,它也能被选为领导者。这些算法都包含一些额外的机制来识别丢失的日志条目并把他们传送给新的领导人,要么是在选举阶段要么在之后很快进行。不幸的是,这种方法会导致相当大的额外的机制和复杂性。Raft 使用了一种更加简单的方法,它可以保证所有之前的任期号中已经提交的日志条目在选举的时候都会出现在新的领导人中,不需要传送这些日志条目给领导人。这意味着日志条目的传送是单向的,只从领导人传给跟随者,并且领导人从不会覆盖自身本地日志中已经存在的条目。

Raft 使用投票的方式来阻止一个候选人赢得选举除非这个候选人包含了所有已经提交的日志条目。候选人为了赢得选举必须联系集群中的大部分节点,这意味着每一个已经提交的日志条目在这些服务器节点中肯定存在于至少一个节点上。如果候选人的日志至少和大多数的服务器节点一样新(这个新的定义会在下面讨论),那么他一定持有了所有已经提交的日志条目。请求投票 RPC 实现了这样的限制: RPC 中包含了候选人的日志信息,然后投票人会拒绝掉那些日志没有自己新的投票请求。

Raft 通过比较两份日志中最后一条日志条目的索引值和任期号定义谁的日志比较新。如果两份日志最后的条目的任期号不同,那么任期号大的日志更加新。如果两份日志最后的条目任期号相同,那么日志比较长的那个就更加新。

5.4.2 提交之前任期内的日志条目

如同 5.3 节介绍的那样,领导人知道一条当前任期内的日志记录是可以被提交的,只要它被存储到了大多数的服务器上。如果一个领导人在提交日志条目之前崩溃了,未来后续的领导人会继续尝试复制这条日志记录。然而,一个领导人不能断定一个之前任期里的日志条目被保存到大多数服务器上的时候就一定已经提交了。图 8 展示了一种情况,一条已经被存储到大多数节点上的老日志条目,也依然有可能会被未来的领导人覆盖掉。

图 8:如图的时间序列展示了为什么领导人无法决定对老任期号的日志条目进行提交。在 (a) 中,S1 是领导者,部分的复制了索引位置 2 的日志条目。在 (b) 中,S1 崩溃了,然后 S5 在任期 3 里通过 S3、S4 和自己的选票赢得选举,然后从客户端接收了一条不一样的日志条目放在了索引 2 处。然后到 (c),S5 又崩溃了;S1 重新启动,选举成功,开始复制日志。在这时,来自任期 2 的那条日志已经被复制到了集群中的大多数机器上,但是还没有被提交。如果 S1 在 (d) 中又崩溃了,S5 可以重新被选举成功(通过来自 S2,S3 和 S4 的选票),然后覆盖了他们在索引 2 处的日志。反之,如果在崩溃之前,S1 把自己主导的新任期里产生的日志条目复制到了大多数机器上,就如 (e) 中那样,那么在后面任期里面这些新的日志条目就会被提交(因为S5 就不可能选举成功)。 这样在同一时刻就同时保证了,之前的所有老的日志条目就会被提交。

为了消除图 8 里描述的情况,Raft 永远不会通过计算副本数目的方式去提交一个之前任期内的日志条目。只有领导人当前任期里的日志条目通过计算副本数目可以被提交;一旦当前任期的日志条目以这种方式被提交,那么由于日志匹配特性,之前的日志条目也都会被间接的提交。在某些情况下,领导人可以安全的知道一个老的日志条目是否已经被提交(例如,该条目是否存储到所有服务器上),但是 Raft 为了简化问题使用一种更加保守的方法。

当领导人复制之前任期里的日志时,Raft 会为所有日志保留原始的任期号, 这在提交规则上产生了额外的复杂性。在其他的一致性算法中,如果一个新的领导人要重新复制之前的任期里的日志时,它必须使用当前新的任期号。Raft 使用的方法更加容易辨别出日志,因为它可以随着时间和日志的变化对日志维护着同一个任期编号。另外,和其他的算法相比,Raft 中的新领导人只需要发送更少日志条目(其他算法中必须在他们被提交之前发送更多的冗余日志条目来为他们重新编号)。

5.4.3 安全性论证

在给定了完整的 Raft 算法之后,我们现在可以更加精确的讨论领导人完整性特性(这一讨论基于 9.2 节的安全性证明)。我们假设领导人完全性特性是不存在的,然后我们推出矛盾来。假设任期 T 的领导人(领导人 T)在任期内提交了一条日志条目,但是这条日志条目没有被存储到未来某个任期的领导人的日志中。设大于 T 的最小任期 U 的领导人 U 没有这条日志条目。

图 9:如果 S1 (任期 T 的领导者)提交了一条新的日志在它的任期里,然后 S5 在之后的任期 U 里被选举为领导人,然后至少会有一个机器,如 S3,既拥有来自 S1 的日志,也给 S5 投票了。

  1. 在领导人 U 选举的时候一定没有那条被提交的日志条目(领导人从不会删除或者覆盖任何条目)。
  2. 领导人 T 复制这条日志条目给集群中的大多数节点,同时,领导人U 从集群中的大多数节点赢得了选票。因此,至少有一个节点(投票者、选民)同时接受了来自领导人T 的日志条目,并且给领导人U 投票了,如图 9。这个投票者是产生这个矛盾的关键。
  3. 这个投票者必须在给领导人 U 投票之前先接受了从领导人 T 发来的已经被提交的日志条目;否则他就会拒绝来自领导人 T 的附加日志请求(因为此时他的任期号会比 T 大)。
  4. 投票者在给领导人 U 投票时依然保有这条日志条目,因为任何中间的领导人都包含该日志条目(根据上述的假设),领导人从不会删除条目,并且跟随者只有和领导人冲突的时候才会删除条目。
  5. 投票者把自己选票投给领导人 U 时,领导人 U 的日志必须和投票者自己一样新。这就导致了两者矛盾之一。
  6. 首先,如果投票者和领导人 U 的最后一条日志的任期号相同,那么领导人 U 的日志至少和投票者一样长,所以领导人 U 的日志一定包含所有投票者的日志。这是另一处矛盾,因为投票者包含了那条已经被提交的日志条目,但是在上述的假设里,领导人 U 是不包含的。
  7. 除此之外,领导人 U 的最后一条日志的任期号就必须比投票人大了。此外,他也比 T 大,因为投票人的最后一条日志的任期号至少和 T 一样大(他包含了来自任期 T 的已提交的日志)。创建了领导人 U 最后一条日志的之前领导人一定已经包含了那条被提交的日志(根据上述假设,领导人 U 是第一个不包含该日志条目的领导人)。所以,根据日志匹配特性,领导人 U 一定也包含那条被提交当然日志,这里产生矛盾。
  8. 这里完成了矛盾。因此,所有比 T 大的领导人一定包含了所有来自 T 的已经被提交的日志。
  9. 日志匹配原则保证了未来的领导人也同时会包含被间接提交的条目,例如图 8 (d) 中的索引 2。

通过领导人完全特性,我们就能证明图 3 中的状态机安全特性,即如果已经服务器已经在某个给定的索引值应用了日志条目到自己的状态机里,那么其他的服务器不会应用一个不一样的日志到同一个索引值上。在一个服务器应用一条日志条目到他自己的状态机中时,他的日志必须和领导人的日志,在该条目和之前的条目上相同,并且已经被提交。现在我们来考虑在任何一个服务器应用一个指定索引位置的日志的最小任期;日志完全特性保证拥有更高任期号的领导人会存储相同的日志条目,所以之后的任期里应用某个索引位置的日志条目也会是相同的值。因此,状态机安全特性是成立的。

最后,Raft 要求服务器按照日志中索引位置顺序应用日志条目。和状态机安全特性结合起来看,这就意味着所有的服务器会应用相同的日志序列集到自己的状态机中,并且是按照相同的顺序。

5.5 跟随者和候选人崩溃

到目前为止,我们都只关注了领导人崩溃的情况。跟随者和候选人崩溃后的处理方式比领导人要简单的多,并且他们的处理方式是相同的。如果跟随者或者候选人崩溃了,那么后续发送给他们的 RPCs 都会失败。Raft 中处理这种失败就是简单的通过无限的重试;如果崩溃的机器重启了,那么这些 RPC 就会完整的成功。如果一个服务器在完成了一个 RPC,但是还没有响应的时候崩溃了,那么在他重新启动之后就会再次收到同样的请求。Raft 的 RPCs 都是幂等的,所以这样重试不会造成任何问题。例如一个跟随者如果收到附加日志请求但是他已经包含了这一日志,那么他就会直接忽略这个新的请求。

5.6 时间和可用性

Raft 的要求之一就是安全性不能依赖时间:整个系统不能因为某些事件运行的比预期快一点或者慢一点就产生了错误的结果。但是,可用性(系统可以及时的响应客户端)不可避免的要依赖于时间。例如,如果消息交换比服务器故障间隔时间长,候选人将没有足够长的时间来赢得选举;没有一个稳定的领导人,Raft 将无法工作。

领导人选举是 Raft 中对时间要求最为关键的方面。Raft 可以选举并维持一个稳定的领导人,只要系统满足下面的时间要求:

广播时间(broadcastTime) << 选举超时时间(electionTimeout) << 平均故障间隔时间(MTBF)

在这个不等式中,广播时间指的是从一个服务器并行的发送 RPCs 给集群中的其他服务器并接收响应的平均时间;选举超时时间就是在 5.2 节中介绍的选举的超时时间限制;然后平均故障间隔时间就是对于一台服务器而言,两次故障之间的平均时间。广播时间必须比选举超时时间小一个量级,这样领导人才能够发送稳定的心跳消息来阻止跟随者开始进入选举状态;通过随机化选举超时时间的方法,这个不等式也使得选票瓜分的情况变得不可能。选举超时时间应该要比平均故障间隔时间小上几个数量级,这样整个系统才能稳定的运行。当领导人崩溃后,整个系统会大约相当于选举超时的时间里不可用;我们希望这种情况在整个系统的运行中很少出现。

广播时间和平均故障间隔时间是由系统决定的,但是选举超时时间是我们自己选择的。Raft 的 RPCs 需要接收方将信息持久化的保存到稳定存储中去,所以广播时间大约是 0.5 毫秒到 20 毫秒,取决于存储的技术。因此,选举超时时间可能需要在 10 毫秒到 500 毫秒之间。大多数的服务器的平均故障间隔时间都在几个月甚至更长,很容易满足时间的需求。

6 集群成员变化

到目前为止,我们都假设集群的配置(加入到一致性算法的服务器集合)是固定不变的。但是在实践中,偶尔是会改变集群的配置的,例如替换那些宕机的机器或者改变复制级别。尽管可以通过暂停整个集群,更新所有配置,然后重启整个集群的方式来实现,但是在更改的时候集群会不可用。另外,如果存在手工操作步骤,那么就会有操作失误的风险。为了避免这样的问题,我们决定自动化配置改变并且将其纳入到 Raft 一致性算法中来。

为了让配置修改机制能够安全,那么在转换的过程中不能够存在任何时间点使得两个领导人同时被选举成功在同一个任期里。不幸的是,任何服务器直接从旧的配置直接转换到新的配置的方案都是不安全的。一次性自动的转换所有服务器是不可能的,所以在转换期间整个集群存在划分成两个独立的大多数群体的可能性(见图 10)。

图 10:直接从一种配置转到新的配置是十分不安全的,因为各个机器可能在任何的时候进行转换。在这个例子中,集群配额从 3 台机器变成了 5 台。不幸的是,存在这样的一个时间点,两个不同的领导人在同一个任期里都可以被选举成功。一个是通过旧的配置,一个通过新的配置。

为了保证安全性,配置更改必须使用两阶段方法。目前有很多种两阶段的实现。例如,有些系统在第一阶段停掉旧的配置所以集群就不能处理客户端请求;然后在第二阶段在启用新的配置。在 Raft 中,集群先切换到一个过渡的配置,我们称之为共同一致;一旦共同一致已经被提交了,那么系统就切换到新的配置上。共同一致是老配置和新配置的结合:

  • 日志条目被复制给集群中新、老配置的所有服务器。
  • 新、旧配置的服务器都可以成为领导人。
  • 达成一致(针对选举和提交)需要分别在两种配置上获得大多数的支持。

共同一致允许独立的服务器在不影响安全性的前提下,在不同的时间进行配置转换过程。此外,共同一致可以让集群在配置转换的过程人依然响应服务器请求。

集群配置在复制日志中以特殊的日志条目来存储和通信;图 11 展示了配置转换的过程。当一个领导人接收到一个改变配置从 C-old 到 C-new 的请求,他会为了共同一致存储配置(图中的 C-old,new),以前面描述的日志条目和副本的形式。一旦一个服务器将新的配置日志条目增加到它的日志中,他就会用这个配置来做出未来所有的决定(服务器总是使用最新的配置,无论他是否已经被提交)。这意味着领导人要使用 C-old,new 的规则来决定日志条目 C-old,new 什么时候需要被提交。如果领导人崩溃了,被选出来的新领导人可能是使用 C-old 配置也可能是 C-old,new 配置,这取决于赢得选举的候选人是否已经接收到了 C-old,new 配置。在任何情况下, C-new 配置在这一时期都不会单方面的做出决定。

一旦 C-old,new 被提交,那么无论是 C-old 还是 C-new,在没有经过他人批准的情况下都不可能做出决定,并且领导人完全特性保证了只有拥有 C-old,new 日志条目的服务器才有可能被选举为领导人。这个时候,领导人创建一条关于 C-new 配置的日志条目并复制给集群就是安全的了。再者,每个服务器在见到新的配置的时候就会立即生效。当新的配置在 C-new 的规则下被提交,旧的配置就变得无关紧要,同时不使用新的配置的服务器就可以被关闭了。如图 11,C-old 和 C-new 没有任何机会同时做出单方面的决定;这保证了安全性。

图 11:一个配置切换的时间线。虚线表示已经被创建但是还没有被提交的条目,实线表示最后被提交的日志条目。领导人首先创建了 C-old,new 的配置条目在自己的日志中,并提交到 C-old,new 中(C-old 的大多数和 C-new 的大多数)。然后他创建 C-new 条目并提交到 C-new 中的大多数。这样就不存在 C-new 和 C-old 可以同时做出决定的时间点。

在关于重新配置还有三个问题需要提出。第一个问题是,新的服务器可能初始化没有存储任何的日志条目。当这些服务器以这种状态加入到集群中,那么他们需要一段时间来更新追赶,这时还不能提交新的日志条目。为了避免这种可用性的间隔时间,Raft 在配置更新的时候使用了一种额外的阶段,在这个阶段,新的服务器以没有投票权身份加入到集群中来(领导人复制日志给他们,但是不考虑他们是大多数)。一旦新的服务器追赶上了集群中的其他机器,重新配置可以像上面描述的一样处理。

第二个问题是,集群的领导人可能不是新配置的一员。在这种情况下,领导人就会在提交了 C-new 日志之后退位(回到跟随者状态)。这意味着有这样的一段时间,领导人管理着集群,但是不包括他自己;他复制日志但是不把他自己算作是大多数之一。当 C-new 被提交时,会发生领导人过渡,因为这时是最早新的配置可以独立工作的时间点(将总是能够在 C-new 配置下选出新的领导人)。在此之前,可能只能从 C-old 中选出领导人。

第三个问题是,移除不在 C-new 中的服务器可能会扰乱集群。这些服务器将不会再接收到心跳,所以当选举超时,他们就会进行新的选举过程。他们会发送拥有新的任期号的请求投票 RPCs,这样会导致当前的领导人回退成跟随者状态。新的领导人最终会被选出来,但是被移除的服务器将会再次超时,然后这个过程会再次重复,导致整体可用性大幅降低。

为了避免这个问题,当服务器确认当前领导人存在时,服务器会忽略请求投票 RPCs。特别的,当服务器在当前最小选举超时时间内收到一个请求投票 RPC,他不会更新当前的任期号或者投出选票。这不会影响正常的选举,每个服务器在开始一次选举之前,至少等待一个最小选举超时时间。然而,这有利于避免被移除的服务器扰乱:如果领导人能够发送心跳给集群,那么他就不会被更大的任期号废黜。

7 日志压缩

Raft 的日志在正常操作中不断的增长,但是在实际的系统中,日志不能无限制的增长。随着日志不断增长,他会占用越来越多的空间,花费越来越多的时间来重置。如果没有一定的机制去清除日志里积累的陈旧的信息,那么会带来可用性问题。

快照是最简单的压缩方法。在快照系统中,整个系统的状态都以快照的形式写入到稳定的持久化存储中,然后到那个时间点之前的日志全部丢弃。快照技术被使用在 Chubby 和 ZooKeeper 中,接下来的章节会介绍 Raft 中的快照技术。

增量压缩的方法,例如日志清理或者日志结构合并树,都是可行的。这些方法每次只对一小部分数据进行操作,这样就分散了压缩的负载压力。首先,他们先选择一个已经积累的大量已经被删除或者被覆盖对象的区域,然后重写那个区域还活跃的对象,之后释放那个区域。和简单操作整个数据集合的快照相比,需要增加复杂的机制来实现。状态机可以实现 LSM tree 使用和快照相同的接口,但是日志清除方法就需要修改 Raft 了。

图 12:一个服务器用新的快照替换了从 1 到 5 的条目,快照值存储了当前的状态。快照中包含了最后的索引位置和任期号。

图 12 展示了 Raft 中快照的基础思想。每个服务器独立的创建快照,只包括已经被提交的日志。主要的工作包括将状态机的状态写入到快照中。Raft 也包含一些少量的元数据到快照中:最后被包含索引指的是被快照取代的最后的条目在日志中的索引值(状态机最后应用的日志),最后被包含的任期指的是该条目的任期号。保留这些数据是为了支持快照前的第一个条目的附加日志请求时的一致性检查,因为这个条目需要最后的索引值和任期号。为了支持集群成员更新(第 6 节),快照中也将最后的一次配置作为最后一个条目存下来。一旦服务器完成一次快照,他就可以删除最后索引位置之前的所有日志和快照了。

尽管通常服务器都是独立的创建快照,但是领导人必须偶尔的发送快照给一些落后的跟随者。这通常发生在当领导人已经丢弃了下一条需要发送给跟随者的日志条目的时候。幸运的是这种情况不是常规操作:一个与领导人保持同步的跟随者通常都会有这个条目。然而一个运行非常缓慢的跟随者或者新加入集群的服务器(第 6 节)将不会有这个条目。这时让这个跟随者更新到最新的状态的方式就是通过网络把快照发送给他们。

安装快照 RPC

在领导人发送快照给跟随者时使用到。领导人总是按顺序发送。

参数 解释
term 领导人的任期号
leaderId 领导人的 Id,以便于跟随者重定向请求
lastIncludedIndex 快照中包含的最后日志条目的索引值
lastIncludedTerm 快照中包含的最后日志条目的任期号
offset 分块在快照中的偏移量
data[] 原始数据
done 如果这是最后一个分块则为 true
结果 解释
term 当前任期号,便于领导人更新自己

接收者实现

  1. 如果term < currentTerm就立即回复
  2. 如果是第一个分块(offset 为 0)就创建一个新的快照
  3. 在指定偏移量写入数据
  4. 如果 done 是 false,则继续等待更多的数据
  5. 保存快照文件,丢弃索引值小于快照的日志
  6. 如果现存的日志拥有相同的最后任期号和索引值,则后面的数据继续保持
  7. 丢弃整个日志
  8. 使用快照重置状态机

图 13:一个关于安装快照的简要概述。为了便于传输,快照都是被分成分块的;每个分块都给了跟随者生命的迹象,所以跟随者可以重置选举超时计时器。

在这种情况下领导人使用一种叫做安装快照的新的 RPC 来发送快照给太落后的跟随者;见图 13。当跟随者通过这种 RPC 接收到快照时,他必须自己决定对于已经存在的日志该如何处理。通常快照会包含没有在接收者日志中存在的信息。在这种情况下,跟随者直接丢弃他所有的日志;这些会被快照所取代,但是可能会和没有提交的日志产生冲突。如果接收到的快照是自己日志的前面部分(由于网络重传或者错误),那么被快照包含的条目将会被全部删除,但是快照之后的条目必须正确和保留。

这种快照的方式背离了 Raft 的强领导人原则,因为跟随者可以在不知道领导人情况下创建快照。但是我们认为这种背离是值得的。领导人的存在,是为了解决在达成一致性的时候的冲突,但是在创建快照的时候,一致性已经达成,这时不存在冲突了,所以没有领导人也是可以的。数据依然是从领导人传给跟随者,只是跟随者可以重新组织他们的数据了。

我们考虑过一种替代的基于领导人的快照方案,即只有领导人创建快照,然后发送给所有的跟随者。但是这样做有两个缺点。第一,发送快照会浪费网络带宽并且延缓了快照处理的时间。每个跟随者都已经拥有了所有产生快照需要的信息,而且很显然,自己从本地的状态中创建快照比通过网络接收别人发来的要经济。第二,领导人的实现会更加复杂。例如,领导人需要发送快照的同时并行的将新的日志条目发送给跟随者,这样才不会阻塞新的客户端请求。

还有两个问题影响了快照的性能。首先,服务器必须决定什么时候应该创建快照。如果快照创建的过于频繁,那么就会浪费大量的磁盘带宽和其他资源;如果创建快照频率太低,他就要承受耗尽存储容量的风险,同时也增加了从日志重建的时间。一个简单的策略就是当日志大小达到一个固定大小的时候就创建一次快照。如果这个阈值设置的显著大于期望的快照的大小,那么快照对磁盘压力的影响就会很小了。

第二个影响性能的问题就是写入快照需要花费显著的一段时间,并且我们还不希望影响到正常操作。解决方案是通过写时复制的技术,这样新的更新就可以被接收而不影响到快照。例如,具有函数式数据结构的状态机天然支持这样的功能。另外,操作系统的写时复制技术的支持(如 Linux 上的 fork)可以被用来创建完整的状态机的内存快照(我们的实现就是这样的)。

8 客户端交互

这一节将介绍客户端是如何和 Raft 进行交互的,包括客户端如何发现领导人和 Raft 是如何支持线性化语义的。这些问题对于所有基于一致性的系统都存在,并且 Raft 的解决方案和其他的也差不多。

Raft 中的客户端发送所有请求给领导人。当客户端启动的时候,他会随机挑选一个服务器进行通信。如果客户端第一次挑选的服务器不是领导人,那么那个服务器会拒绝客户端的请求并且提供他最近接收到的领导人的信息(附加条目请求包含了领导人的网络地址)。如果领导人已经崩溃了,那么客户端的请求就会超时;客户端之后会再次重试随机挑选服务器的过程。

我们 Raft 的目标是要实现线性化语义(每一次操作立即执行,只执行一次,在他调用和收到回复之间)。但是,如上述,Raft 是可以执行同一条命令多次的:例如,如果领导人在提交了这条日志之后,但是在响应客户端之前崩溃了,那么客户端会和新的领导人重试这条指令,导致这条命令就被再次执行了。解决方案就是客户端对于每一条指令都赋予一个唯一的序列号。然后,状态机跟踪每条指令最新的序列号和相应的响应。如果接收到一条指令,它的序列号已经被执行了,那么就立即返回结果,而不重新执行指令。

只读的操作可以直接处理而不需要记录日志。但是,在不增加任何限制的情况下,这么做可能会冒着返回脏数据的风险,因为领导人响应客户端请求时可能已经被新的领导人作废了,但是他还不知道。线性化的读操作必须不能返回脏数据,Raft 需要使用两个额外的措施在不使用日志的情况下保证这一点。首先,领导人必须有关于被提交日志的最新信息。领导人完全特性保证了领导人一定拥有所有已经被提交的日志条目,但是在他任期开始的时候,他可能不知道那些是已经被提交的。为了知道这些信息,他需要在他的任期里提交一条日志条目。Raft 中通过领导人在任期开始的时候提交一个空白的没有任何操作的日志条目到日志中去来实现。第二,领导人在处理只读的请求之前必须检查自己是否已经被废黜了(他自己的信息已经变脏了如果一个更新的领导人被选举出来)。Raft 中通过让领导人在响应只读请求之前,先和集群中的大多数节点交换一次心跳信息来处理这个问题。可选的,领导人可以依赖心跳机制来实现一种租约的机制,但是这种方法依赖时间来保证安全性(假设时间误差是有界的)。

9 算法实现和评估

我们已经为 RAMCloud 实现了 Raft 算法作为存储配置信息的复制状态机的一部分,并且帮助 RAMCloud 协调故障转移。这个 Raft 实现包含大约 2000 行 C++ 代码,其中不包括测试、注释和空行。这些代码是开源的。同时也有大约 25 个其他独立的第三方的基于这篇论文草稿的开源实现,针对不同的开发场景。同时,很多公司已经部署了基于 Raft 的系统。

这一节会从三个方面来评估 Raft 算法:可理解性、正确性和性能。

9.1 可理解性

为了和 Paxos 比较 Raft 算法的可理解能力,我们针对高层次的本科生和研究生,在斯坦福大学的高级操作系统课程和加州大学伯克利分校的分布式计算课程上,进行了一次学习的实验。我们分别拍了针对 Raft 和 Paxos 的视频课程,并准备了相应的小测验。Raft 的视频讲课覆盖了这篇论文的所有内容除了日志压缩;Paxos 讲课包含了足够的资料来创建一个等价的复制状态机,包括单决策 Paxos,多决策 Paxos,重新配置和一些实际系统需要的性能优化(例如领导人选举)。小测验测试一些对算法的基本理解和解释一些边角的示例。每个学生都是看完第一个视频,回答相应的测试,再看第二个视频,回答相应的测试。大约有一半的学生先进行 Paxos 部分,然后另一半先进行 Raft 部分,这是为了说明两者独立的区别从第一个算法处学来的经验。我们计算参加人员的每一个小测验的得分来看参与者是否在 Raft 算法上更加容易理解。

我们尽可能的使得 Paxos 和 Raft 的比较更加公平。这个实验偏爱 Paxos 表现在两个方面:43 个参加者中有 15 个人在之前有一些 Paxos 的经验,并且 Paxos 的视频要长 14%。如表格 1 总结的那样,我们采取了一些措施来减轻这种潜在的偏见。我们所有的材料都可供审查。

关心 缓和偏见采取的手段 可供查看的材料
相同的讲课质量 两者使用同一个讲师。Paxos 使用的是现在很多大学里经常使用的。Paxos 会长 14%。 视频
相同的测验难度 问题以难度分组,在两个测验里成对出现。 小测验
公平评分 使用红字标题。随机顺序打分,两个测验交替进行。 红字标题

表 1:考虑到可能会存在的偏见,对于每种情况的解决方法,和相应的材料。

参加者平均在 Raft 的测验中比 Paxos 高 4.9 分(总分 60,那么 Raft 的平均得分是 25.7,而 Paxos 是 20.8);图 14 展示了每个参与者的得分。一对 t -测试表明,拥有 95% 的可信度,真实的 Raft 分数分布至少比 Paxos 高 2.5 分。

图 14:一个散点图表示了 43 个学生在 Paxos 和 Raft 的小测验中的成绩。在对角线之上的点表示在 Raft 获得了更高分数的学生。

我们也建立了一个线性回归模型来预测一个新的学生的测验成绩,基于以下三个因素:他们使用的是哪个小测验,之前对 Paxos 的经验,和学习算法的顺序。模型显示,对小测验的选择会产生 12.5 分的差别在对 Raft 的好感度上。这显著的高于之前的 4.9 分,因为很多学生在之前都已经有了对于 Paxos 的经验,这相当明显的帮助 Paxos,对 Raft 就没什么太大影响了。但是奇怪的是,模型预测对于先进性 Paxos 小测验的人而言,Raft 的小测验得分会比 Paxos 低 6.3 分;我们不知道为什么,但这在统计学上是这样的。

我们同时也在测验之后调查了参与者,他们认为哪个算法更加容易实现和解释;这个的结果在图 15 上。压倒性的结果表明 Raft 算法更加容易实现和解释(41 人中的 33个)。但是,这种自己报告的结果不如参与者的成绩更加可信,并且参与者可能因为我们的 Raft 更加易于理解的假说而产生偏见。

图 15:通过一个 5 分制的问题,参与者(左边)被问哪个算法他们觉得在一个高效正确的系统里更容易实现,右边被问哪个更容易向学生解释。

关于 Raft 用户学习有一个更加详细的讨论。

9.2 正确性

在第 5 节,我们已经进行了一个正式的说明,和对一致性机制的安全性证明。这个正式说明让图 2 中的信息非常清晰通过 TLA+ 说明语言。大约 400 行说明充当了证明的主题。同时对于任何想实现的人也是十分有用的。我们非常机械的证明了日志完全特性通过 TLA 证明系统。然而,这个证明依赖的约束前提还没有被机械证明(例如,我们还没有证明这个说明中的类型安全)。而且,我们已经写了一个非正式的证明关于状态机安全性质是完备的,并且是相当清晰的(大约 3500 个词)。

9.3 性能

Raft 和其他一致性算法例如 Paxos 有着差不多的性能。在性能方面,最重要的关注点是,当领导人被选举成功时,什么时候复制新的日志条目。Raft 通过很少数量的消息包(一轮从领导人到集群大多数机器的消息)就达成了这个目的。同时,进一步提升 Raft 的性能也是可行的。例如,很容易通过支持批量操作和管道操作来提高吞吐量和降低延迟。对于其他一致性算法已经提出过很多性能优化方案;其中有很多也可以应用到 Raft 中来,但是我们暂时把这个问题放到未来的工作中去。

我们使用我们自己的 Raft 实现来衡量 Raft 领导人选举的性能并且回答两个问题。首先,领导人选举的过程收敛是否快速?第二,在领导人宕机之后,最小的系统宕机时间是多久?

图 16:发现并替换一个已经崩溃的领导人的时间。上面的图考察了在选举超时时间上的随机化程度,下面的图考察了最小超时时间。每条线代表了 1000 次实验(除了 150-150 毫秒只试了 100 次),和相应的确定的选举超时时间。例如,150-155 毫秒意思是,选举超时时间从这个区间范围内随机选择并确定下来。这个实验在一个拥有 5 个节点的集群上进行,其广播时延大约是 15 毫秒。对于 9 个节点的集群,结果也差不多。

为了衡量领导人选举,我们反复的使一个拥有五个节点的服务器集群的领导人宕机,并计算需要多久才能发现领导人已经宕机并选出一个新的领导人(见图 16)。为了构建一个最坏的场景,在每一的尝试里,服务器都有不同长度的日志,意味着有些候选人是没有成为领导人的资格的。另外,为了促成选票瓜分的情况,我们的测试脚本在终止领导人之前同步的发送了一次心跳广播(这大约和领导人在崩溃前复制一个新的日志给其他机器很像)。领导人均匀的随机的在心跳间隔里宕机,也就是最小选举超时时间的一半。因此,最小宕机时间大约就是最小选举超时时间的一半。

图 16 上面的图表表明,只需要在选举超时时间上使用很少的随机化就可以大大避免选票被瓜分的情况。在没有随机化的情况下,在我们的测试里,选举过程往往都需要花费超过 10 秒钟由于太多的选票瓜分的情况。仅仅增加 5 毫秒的随机化时间,就大大的改善了选举过程,现在平均的宕机时间只有 287 毫秒。增加更多的随机化时间可以大大改善最坏情况:通过增加 50 毫秒的随机化时间,最坏的完成情况(1000 次尝试)只要 513 毫秒。

图 16 中下面的图显示,通过减少选举超时时间可以减少系统的宕机时间。在选举超时时间为 12-24 毫秒的情况下,只需要平均 35 毫秒就可以选举出新的领导人(最长的一次花费了 152 毫秒)。然而,进一步降低选举超时时间的话就会违反 Raft 的时间不等式需求:在选举新领导人之前,领导人就很难发送完心跳包。这会导致没有意义的领导人改变并降低了系统整体的可用性。我们建议使用更为保守的选举超时时间,比如 150-300 毫秒;这样的时间不大可能导致没有意义的领导人改变,而且依然提供不错的可用性。

10 相关工作

已经有很多关于一致性算法的工作被发表出来,其中很多都可以归到下面的类别中:

  • Lamport 关于 Paxos 的原始描述,和尝试描述的更清晰。
  • 关于 Paxos 的更详尽的描述,补充遗漏的细节并修改算法,使得可以提供更加容易的实现基础。
  • 实现一致性算法的系统,例如 Chubby,ZooKeeper 和 Spanner。对于 Chubby 和 Spanner 的算法并没有公开发表其技术细节,尽管他们都声称是基于 Paxos 的。ZooKeeper 的算法细节已经发表,但是和 Paxos 着实有着很大的差别。
  • Paxos 可以应用的性能优化。
  • Oki 和 Liskov 的 Viewstamped Replication(VR),一种和 Paxos 差不多的替代算法。原始的算法描述和分布式传输协议耦合在了一起,但是核心的一致性算法在最近的更新里被分离了出来。VR 使用了一种基于领导人的方法,和 Raft 有很多相似之处。

Raft 和 Paxos 最大的不同之处就在于 Raft 的强领导特性:Raft 使用领导人选举作为一致性协议里必不可少的部分,并且将尽可能多的功能集中到了领导人身上。这样就可以使得算法更加容易理解。例如,在 Paxos 中,领导人选举和基本的一致性协议是正交的:领导人选举仅仅是性能优化的手段,而且不是一致性所必须要求的。但是,这样就增加了多余的机制:Paxos 同时包含了针对基本一致性要求的两阶段提交协议和针对领导人选举的独立的机制。相比较而言,Raft 就直接将领导人选举纳入到一致性算法中,并作为两阶段一致性的第一步。这样就减少了很多机制。

像 Raft 一样,VR 和 ZooKeeper 也是基于领导人的,因此他们也拥有一些 Raft 的优点。但是,Raft 比 VR 和 ZooKeeper 拥有更少的机制因为 Raft 尽可能的减少了非领导人的功能。例如,Raft 中日志条目都遵循着从领导人发送给其他人这一个方向:附加条目 RPC 是向外发送的。在 VR 中,日志条目的流动是双向的(领导人可以在选举过程中接收日志);这就导致了额外的机制和复杂性。根据 ZooKeeper 公开的资料看,它的日志条目也是双向传输的,但是它的实现更像 Raft。

和上述我们提及的其他基于一致性的日志复制算法中,Raft 的消息类型更少。例如,我们数了一下 VR 和 ZooKeeper 使用的用来基本一致性需要和成员改变的消息数(排除了日志压缩和客户端交互,因为这些都比较独立且和算法关系不大)。VR 和 ZooKeeper 都分别定义了 10 中不同的消息类型,相对的,Raft 只有 4 中消息类型(两种 RPC 请求和对应的响应)。Raft 的消息都稍微比其他算法的要信息量大,但是都很简单。另外,VR 和 ZooKeeper 都在领导人改变时传输了整个日志;所以为了能够实践中使用,额外的消息类型就很必要了。

Raft 的强领导人模型简化了整个算法,但是同时也排斥了一些性能优化的方法。例如,平等主义 Paxos (EPaxos)在某些没有领导人的情况下可以达到很高的性能。平等主义 Paxos 充分发挥了在状态机指令中的交换性。任何服务器都可以在一轮通信下就提交指令,除非其他指令同时被提出了。然而,如果指令都是并发的被提出,并且互相之间不通信沟通,那么 EPaxos 就需要额外的一轮通信。因为任何服务器都可以提交指令,所以 EPaxos 在服务器之间的负载均衡做的很好,并且很容易在 WAN 网络环境下获得很低的延迟。但是,他在 Paxos 上增加了非常明显的复杂性。

一些集群成员变换的方法已经被提出或者在其他的工作中被实现,包括 Lamport 的原始的讨论,VR 和 SMART。我们选择使用共同一致的方法因为他对一致性协议的其他部分影响很小,这样我们只需要很少的一些机制就可以实现成员变换。Lamport 的基于 α 的方法之所以没有被 Raft 选择是因为它假设在没有领导人的情况下也可以达到一致性。和 VR 和 SMART 相比较,Raft 的重新配置算法可以在不限制正常请求处理的情况下进行;相比较的,VR 需要停止所有的处理过程,SMART 引入了一个和 α 类似的方法,限制了请求处理的数量。Raft 的方法同时也需要更少的额外机制来实现,和 VR、SMART 比较而言。

11 结论

算法的设计通常会把正确性,效率或者简洁作为主要的目标。尽管这些都是很有意义的目标,但是我们相信,可理解性也是一样的重要。在开发者把算法应用到实际的系统中之前,这些目标没有一个会被实现,这些都会必然的偏离发表时的形式。除非开发人员对这个算法有着很深的理解并且有着直观的感觉,否则将会对他们而言很难在实现的时候保持原有期望的特性。

在这篇论文中,我们尝试解决分布式一致性问题,但是一个广为接受但是十分令人费解的算法 Paxos 已经困扰了无数学生和开发者很多年了。我们创造了一种新的算法 Raft,显而易见的比 Paxos 要容易理解。我们同时也相信,Raft 也可以为实际的实现提供坚实的基础。把可理解性作为设计的目标改变了我们设计 Raft 的方式;这个过程是我们发现我们最终很少有技术上的重复,例如问题分解和简化状态空间。这些技术不仅提升了 Raft 的可理解性,同时也使我们坚信其正确性。

12 感谢

这项研究必须感谢以下人员的支持:Ali Ghodsi,David Mazie`res,和伯克利 CS 294-91 课程、斯坦福 CS 240 课程的学生。Scott Klemmer 帮我们设计了用户调查,Nelson Ray 建议我们进行统计学的分析。在用户调查时使用的关于 Paxos 的幻灯片很大一部分是从 Lorenzo Alvisi 的幻灯片上借鉴过来的。特别的,非常感谢 DavidMazieres 和 Ezra Hoch,他们找到了 Raft 中一些难以发现的漏洞。许多人提供了关于这篇论文十分有用的反馈和用户调查材料,包括 Ed Bugnion,Michael Chan,Hugues Evrard,Daniel Giffin,Arjun Gopalan,Jon Howell,Vimalkumar Jeyakumar,Ankita Kejriwal,Aleksandar Kracun,Amit Levy,Joel Martin,Satoshi Matsushita,Oleg Pesok,David Ramos,Robbert van Renesse,Mendel Rosenblum,Nicolas Schiper,Deian Stefan,Andrew Stone,Ryan Stutsman,David Terei,Stephen Yang,Matei Zaharia 以及 24 位匿名的会议审查人员(可能有重复),并且特别感谢我们的领导人 Eddie Kohler。Werner Vogels 发了一条早期草稿链接的推特,给 Raft 带来了极大的关注。我们的工作由 Gigascale 系统研究中心和 Multiscale 系统研究中心给予支持,这两个研究中心由关注中心研究程序资金支持,一个是半导体研究公司的程序,由 STARnet 支持,一个半导体研究公司的程序由 MARCO 和 DARPA 支持,在国家科学基金会的 0963859 号批准,并且获得了来自 Facebook,Google,Mellanox,NEC,NetApp,SAP 和 Samsung 的支持。Diego Ongaro 由 Junglee 公司,斯坦福的毕业团体支持。

参考

 

原文:

https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md

 

发表在 protocol | Raft一致性算法论文的中文翻译已关闭评论

raft

 

概述

引用论文中的第一句话--“Raft 是一种为了管理复制日志的一致性算法”。从两个角度来理解raft算法,第一部分是raft的基本规则,第二部分是raft的异常情况处理。下面放一张raft论文中的经典图来了解一下raft是怎么在一个系统中工作的。下图中一致性模块Consensus Module执行的就是raft算法,它保证拷贝到所有server上的每一条日志是一致的。State Machine状态机对应我们的业务逻辑,日志作为状态机的输入,输入一致就能保证输出是一致的。

基本规则

raft的工作模式是一个Leader和多个Follower模式,即我们通常说的领导者-追随者模式。这种模式下需要解决的第一个问题就是Leader的选举问题。其次是如何把日志从Leader复制到所有Follower上去。这里先不关心安全和可靠性,只理解raft运行起来基本规则。raft中的server有三种状态,除了已经提到的Leader和Follower状态外,还有Candidate状态,即竞选者状态。下面是这三种状态的转化过程。

1、Leader的选举过程

raft初始状态时所有server都处于Follower状态,并且随机睡眠一段时间,这个时间在0~1000ms之间。最先醒来的server A进入Candidate状态,Candidate状态的server A有权利发起投票,向其它所有server发出requst_vote请求,请求其它server给它投票成为Leader。当其它server收到request_vote请求后,将自己仅有的一票投给server A,同时继续保持Follower状态并重置选举计时器。当server A收到大多数(超过一半以上)server的投票后,就进入Leader状态,成为系统中仅有的Leader。raft系统中只有Leader才有权利接收并处理client请求,并向其它server发出添加日志请求来提交日志。

2、日志复制过程

Leader选举出来后,就可以开始处理客户端请求。Leader收到客户端请求后,将请求内容作为一条log日志添加到自己的log记录中,并向其它server发送append_entries(添加日志)请求。其它server收到append_entries请求后,判断该append请求满足接收条件(接收条件在后面安全保证问题3给出),如果满足条件就将其添加到本地的log中,并给Leader发送添加成功的response。Leader在收到大多数server添加成功的response后,就将该条log正式提交。提交后的log日志就意味着已经被raft系统接受,并能应用到状态机中了。

Leader具有绝对的日志复制权力,其它server上存在日志不全或者与Leader日志不一致的情况时,一切都以Leader上的日志为主,最终所有server上的日志都会复制成与Leader一致的状态。

以上就是raft允许的基本规则,如果不出现任何异常情况,那么只要上面两个过程就能使raft运行起来了。但是现实的系统不可能这么一帆风顺,总是有很多异常情况需要考虑。raft的复杂性就来源于对这些异常情况的考虑,下面一小节就以问答的方式来总结raft是怎么保证安全性的。

安全性保证

1、Leader选举过程中,如果有两个serverA和B同时醒来并发出request_vote请求怎么办?

由于在一次选举过程中,一个server最多只能投一票,这就保证了serverA和B不可能同时得到大多数(一半以上)的投票。如果A或者B中其一幸运地得到了大多数投票,就能顺利地成为Leader,raft系统正常运行下去。但是A和B可能刚好都得到一半的投票,两者都成为不了Leader。这时A和B继续保持Candidate状态,并且随机睡眠一段时间,等待进入到下一个选举周期。由于所有server都是随机选择睡眠时间,所以连续出现多个server竞选的概率很低。

2、Leader挂了后,如何选举出新的Leader?

Leader正常运作时,会周期性地发出append_entries请求。这个周期性的append_entries除了可以更新其它Follower的log信息,另外一个重要功能就是起到心跳作用。Follower收到append_entries后,就知道Leader还活着。如果Follower经过一个预定的时间(一般设为2000ms左右)都没有收到Leader的心跳,就认为Leader挂了。于是转入Candidate状态,开始发起投票竞选新的Leader。每个新的Leader产生后就是一个新的任期,每个任期都对应一个唯一的任期号term。这个term是单调递增的,用来唯一标识一个Leader的任期。投票开始时,Candidate将自己的term加1,并在request_vote中带上term;Follower只会接受任期号term比自己大的request_vote请求,并为之投票。这条规则保证了只有最新的Candidate才有可能成为Leader。

3、Follower在收到一条append_entries添加日志请求后,是否立即保存并将其应用到状态机中去?如果不是立即应用,那么由什么来决定该条日志生效的时间?

Follower在收到一条append_entries后,首先会检查这条append_entries的来源信息是否与本地保存的leader信息符合,包括leaderId和任期号term。检查合法后就将日志保存到本地log中,并给Leader回复添加log成功,但是不会立即将其应用到本地状态机。Leader收到大部分Follower添加log成功的回复后,就正式将这条日志commit提交。Leader在随后发出的心跳append_entires中会带上已经提交日志索引。Follower收到Leader发出的心跳append_entries后,就可以确认刚才的log已经被commit(提交)了,这个时候Follower才会把日志应用到本地状态机。下表即是append_entries请求的内容,其中leaderCommit即是Leader已经确认提交的最大日志索引。Follower在收到Leader发出的append_entries后即可以通过leaderCommit字段决定哪些日志可以应用到状态机。

4、假设有一个server A宕机了很长一段时间,它的日志已经落后很多。如果A重新上线,而且此时现有Leader挂掉,server A刚好竞选成为了Leader。按照日志都是由Leader复制给其它server的原则,server A会把其它Follower已经提交的日志给抹掉,而这违反了raft状态机安全特性,raft怎么解决这种异常情况?

所谓的状态机安全特性即是“如果一个领导人已经在给定的索引值位置的日志条目应用到状态机中,那么其他任何的服务器在这个索引位置不会提交一个不同的日志”。如果server在竞选Leader的过程中不加任何限制的话,携带旧日志的server也有可能竞选成为Leader,就必然存在覆盖之前Leader已经提交的日志可能性,从而违反状态机安全特性。raft的解决办法很简单,就是只有具有最新日志的server的才有资格去竞选当上Leader,具体是怎么做到的呢?首先任何server都还是有资格去发起request_vote请求去拉取投票的,request_vote中会带上server的日志信息,这些信息标明了server日志的新旧程度,如下表所示。

其它server收到request_vote后,判断如果lastLogTerm比自己的term大,那么就可以给它投票;lastLogTerm比自己的term小,就不给它投票。如果相等的话就比较lastLogIndex,lastLogIndex大的话日志就比较新,就给它投票。下图是raft日志格式,每条日志中不仅保存了日志内容,还保存了发送这条日志的Leader的任期号term。为什么要在日志里保存任期号term,由于任期号是全局单调递增且唯一的,所以根据任期号可以判断一条日志的新旧程度,为选举出具有最新日志的Leader提供依据。

5、存在如下图一种异常情况,server S5在时序(d)中覆盖了server S1在时序(c)中提交的index为2的日志,方框中的数字是日志的term。这违反了状态机的安全特性--“如果一个领导人已经在给定的索引值位置的日志条目应用到状态机中,那么其他任何的服务器在这个索引位置不会提交一个不同的日志”,raft要如何解决这个问题?

出现这个问题的根本原因是S1在时序(c) 的任期4内提交了一个之前任期2的log,这样S1提交的日志中最大的term仅仅是2,那么一些日志比较旧的server,比如S5(它最日志的term为 3),就有机会成为leader,并覆盖S1提交的日志。解决办法就是S1在时序(c)的任期term4提交term2的旧日志时,旧日志必须附带在当前term 4的日志下一起提交。这样就把S1日志的最大term提高到了4,让那些日志比较旧的S5没有机会竞选成为Leader,也就不会用旧的日志覆盖已经提交的日志了。

简单点说,Leader如果要提交之前term的旧日志,那么必须要提交一条当前term的日志。提交一条当前term的日志相当于为那些旧的日志加了一把安全锁,让那些日志比较旧的server失去得到Leader的机会,从而不会修改那些之前term的旧日志。

怎么具体实现旧日志必须附带在当前term的日志下一起提交呢?在问题3中有给出append_entries请求中的字段,其中有两个字段preLogIndex和preLogTerm的作用没有提到,这两个字段就是为了保证Leader和Followers的历史日志完全一致而存在的。当Leader在提交一条新日志的时候,会带上新日志前一条日志的index和term,即preLogIndex和preLogTerm。Follower收到append_entries后,会检查preLogIndex和preLogTerm是否和自己当前最新那条日志的index和term对得上,如果对不上就会给Leader返回自己当前日志的index和term。Leader收到后就将Follower返回的index对应的日志以及对应的preLogIndex和preLogTerm发送给Follower。这个过程一直重复,直到Leader和Follower找到了第一个index和term能对得上的日志,然后Leader从这条日志开始拷贝给Follower。回答段首的问题,Leader在提交一条最新的日志时,Follow会检验之前的日志是否与Leader保持了一致,如果不一致会一直同步到与Leader一致后才添加最新的日志,这个机制就保证了Leader在提交最新日志时,也提交了之前旧的日志。

6、向raft系统中添加新机器时,由于配置信息不可能在各个系统上同时达到同步状态,总会有某些server先得到新机器的信息,有些server后得到新机器的信息。比如下图raft系统中新增加了server4和server5这两台机器。只有server3率先感知到了这两台机器的添加。这个时候如果进行选举,就有可能出现两个Leader选举成功。因为server3认为有3台server给它投了票,它就是Leader,而server1认为只要有2台server给它投票就是Leader了。raft怎么解决这个问题呢?

产生这个问题的根本原因是,raft系统中有一部分机器使用了旧的配置,如server1和server2,有一部分使用新的配置,如server3。解决这个问题的方法是添加一个中间配置(Cold, Cnew),这个中间配置的内容是旧的配置表Cold和新的配置Cnew。还是拿上图中的例子来说明,这个时候server3收到添加机器的消息后,不是直接使用新的配置Cnew,而是使用(Cold, Cnew)来做决策。比如说server3在竞选Leader的时候,不仅需要得到Cold中的大部分投票,还要得到Cnew中的大部分投票才能成为Leader。这样就保证了server1和server2在使用Cold配置的情况下,还是只可能产生一个Leader。当所有server都获得了添加机器的消息后,再统一切换到Cnew。raft实现中,将Cold,(Cold,Cnew)以及Cnew都当成一条普通的日志。配置更改信息发送Leader后,由Leader先添加一条 (Cold, Cnew)日志,并同步给其它Follower。当这条日志(Cold, Cnew)提交后,再添加一条Cnew日志同步给其它Follower,通过Cnew日志将所有Follower的配置切换到最新。

有的raft实现采用了一种更加简单粗暴的方法来解决成员变化的问题。这个办法就是每次只更新一台机器的配置变化,收到配置变化的机器立马采用新的配置。这样的做法为什么能确保安全性呢?下面举例说明。比如说系统中原来有5台机器A,B,C,D,E,现在新加了一台机器F,A,B,C三台机器没有感知到F的加入,只有D,E两台机器感知到了F的加入。现在就有了两个旧机器集合X{A, B, C, D, E}和新机器集合Y{F}。假设A和D同时进入Candidate状态去竞选Leader,其中D要想竞选成功,必须得有一半以上机器投票,即6/2+1=4台机器,就算Y集合中的F机器给D投了票,还得至少在集合X中得到3票;而A要想竞选成功,也必须得到5/2+1 = 3张票,由于A只知道集合X的存在,所以也必须从集合X中获得至少3票。而A和D不可能同时从集合X同时获得3票,所以A和D不可能同时竞选成为Leader,从而保证了安全性。可以使用更加形式化的数学公式来证明一次添加一台机器配置不会导致产生两个Leader,证明过程就暂时省略了。

 

参考资料

raft论文中文翻译:https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md

raft论文英文原址:https://raft.github.io/raft.pdf

raft使用C语言实现:https://github.com/willemt/raft

raft成员变更过程分析:http://blog.csdn.net/zhang_shuai_2011/article/details/38585725

作者:asmer
链接:https://www.jianshu.com/p/4711c4c32aab
來源:简书

 

其它参考

解读Raft(一 算法基础): https://www.cnblogs.com/hzmark/p/raft.html

解读Raft(二 选举和日志复制):https://www.cnblogs.com/hzmark/p/raft_2.html

解读Raft(三 安全性):https://www.cnblogs.com/hzmark/p/raft_3.html

解读Raft(四 成员变更):https://www.cnblogs.com/hzmark/p/raft_4.html

 

..

 

 

 

发表在 protocol | raft已关闭评论

Jsp EL

1、什么是EL

        EL是JSP表达式语言,全称是ExpressionLanguage,使用EL的目的是简化在JSP中访问变量的方式,简单静态HTML与Java代码的耦合。

2、JSP EL 表达式用于以下情形

静态文本
标准标签和自定义标签
安装支持Servlet2.4/JSP2.0的Container

3、基本语法格式

${ EL Expression}

示例:
${ “Helloworld” }  //输出字符串常量
${ str }  //输出字符串变量str的值
${ 3 + 2 }  //输出3+2的结果
${ user.name} //输出user对象的name属性
${user[“name”] }  //同上
${ sessionScope[“user”].name } //同上
${user.name}
访问对象user的getName()方法以得到name成员的值。
${list[1]}
访问list对象的第二项。
${map[“key”]}
访问map指定键的值。

4、操作符

算术操作符(+,-,*,/,%)
逻辑操作符(&&,||,!或and,or,not)
XML操作符
lt  <
le  <=
gt   >
ge  >=
比较操作符(>,>=,<,<=,==,!==)—可以自动转换数据类型
空操作符(empty)//当值为null时返回true

EL的算术运算符和Java中的运算符的大致相同,优先级也相同。

注意:'+' 运算符不会连接字符串了,他只用于加法运算。

EL关系运算符有以下六个运算符

关系运算符      说明                范例             结果
= = 或 eq   |    等于   |${ 5 = = 5 } 或 ${ 5 eq 5 } | true
!= 或 ne    |   不等于 |${ 5 != 5 } 或 ${ 5 ne 5 } | false
< 或 lt     |   小于    |${ 3 < 5 }或 ${ 3 lt 5 }    | true
> 或 gt     |   大于    |${ 3 > 5 }或 ${ 3 gt 5 }    | false
<= 或 le    | 小于等于 |${ 3 <= 5 }或 ${ 3 le 5 }   | true
>= 或 ge    | 大于等于 |${ 3 >= 5 }或 ${ 3 ge 5 }   | false

5、集合访问

数组访问

${}   //如request.getAttribute(“name”);

List访问
Map访问

6、隐式对象

JSP 表达式语言定义了一组隐式对象,其中许多对象在 JSP scriplet 和表达式中可用:

允许对以下对象进行简易访问:

术语 定义

param

将请求参数名称映射到单个字符串参数值(通过调用 ServletRequest.getParameter (String name) 获得)。getParameter (String) 方法返回带有特定名称的参数。表达式 $(param.name) 相当于 request.getParameter (name)。

paramValues

将请求参数名称映射到一个数值数组(通过调用 ServletRequest.getParameter (String name) 获得)。它与 param 隐式对象非常类似,但它检索一个字符串数组而不是单个值。表达式 ${paramvalues.name) 相当于 request.getParamterValues(name)。

header

将请求头名称映射到单个字符串头值(通过调用 ServletRequest.getHeader(String name) 获得)。表达式 ${header.name} 相当于 request.getHeader(name)。

headerValues

将请求头名称映射到一个数值数组(通过调用 ServletRequest.getHeaders(String) 获得)。它与头隐式对象非常类似。表达式 ${headerValues.name} 相当于 request.getHeaderValues(name)。

cookie 将 cookie 名称映射到单个 cookie 对象。向服务器发出的客户端请求可以获得一个或多个 cookie。表达式 ${cookie.name.value} 返回带有特定名称的第一个 cookie 值。如果请求包含多个同名的 cookie,则应该使用 ${headerValues.name} 表达式。
initParam 将上下文初始化参数名称映射到单个值(通过调用 ServletContext.getInitparameter(String name) 获得)。

除了上述两种类型的隐式对象之外,还有些对象允许访问多种范围的变量,如 Web 上下文、会话、请求、页面:

术语 定义

pageScope

将页面范围的变量名称映射到其值。例如,EL 表达式可以使用 ${pageScope.objectName} 访问一个 JSP 中页面范围的对象,还可以使用 ${pageScope.objectName.attributeName} 访问对象的属性。

requestScope

将请求范围的变量名称映射到其值。该对象允许访问请求对象的属性。例如,EL 表达式可以使用 ${requestScope.objectName} 访问一个 JSP 请求范围的对象,还可以使用 ${requestScope.objectName.attributeName} 访问对象的属性。

sessionScope

将会话范围的变量名称映射到其值。该对象允许访问会话对象的属性。例如:

$sessionScope.name}

applicationScope

将应用程序范围的变量名称映射到其值。该隐式对象允许访问应用程序范围的对象

 特别说明:

cookie对象

所谓的cookie是一个小小的文本文件,它是以key、value的方式将SessionTracking的内容记录在这个文本文件内,这个文本文件通常存在于浏览器的暂存区内。JSTL并没有提供设定cookie的动作,因为这个动作通常都 是后端开发者必须去做的事情,而不是交给前端的开发者。如果我们在cookie中设定一个名称为userCountry的值,那么可以使 用${cookie.userCountry}来取得它。

header和headerValues(请求报头对象)
header储存用户浏览器和服务端用来沟通的数据,当用户要求服务端的网页时,会送出一个记载要求信息的标头文件,例如:用户浏览器的版本、用户计算机所设定的区域等其他相关数据。如果要取得用户浏览器的版本,即${header["User-Agent"]}。另外在很少机会下,有可能同一标头名称拥有不同的值,此时必须改为使用headerValues来取得这些值。
注意:因为User-Agent中包含“-”这个特殊字符,所以必须使用“[]”,而不能写成${header.User-Agent}。
initParam
就像其他属性一样,我们可以自行设定web应用的环境参数(Context),当我们想取得这些参数时,可以使用initParam隐含对象去取得它,例如:当我们在web.xml中设定如下:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<context-param>
<param-name>userid</param-name>
<param-value>mike</param-value>
</context-param>
</web-app>
那么我们就可以直接使用 ${initParam.userid}来取得名称为userid,其值为mike的参数。下面是之前的做法:String userid =(String)application.getInitParameter("userid");

pageContext对象

我们可以使用 ${pageContext}来取得其他有关用户要求或页面的详细信息。下面列出了几个比较常用的部分。
Expression 说 明
${pageContext.request} |取得请求对象
${pageContext.session} |取得session对象
${pageContext.request.queryString} |取得请求的参数字符串
${pageContext.request.requestURL} |取得请求的URL,但不包括请求之参数字符串
${pageContext.request.contextPath} |服务的web application的名称
${pageContext.request.method} |取得HTTP的方法(GET、POST)
${pageContext.request.protocol} |取得使用的协议(HTTP/1.1、HTTP/1.0)
${pageContext.request.remoteUser} |取得用户名称
${pageContext.request.remoteAddr } |取得用户的IP地址
${pageContext.session.new} |判断session是否为新的,所谓新的session,表示刚由 server产生而client尚未使用
${pageContext.session.id} |取得session的ID
${pageContext.servletContext.serverInfo}|取得主机端的服务信息

7、特别强调

1、注意当表达式根据名称引用这些对象之一时,返回的是相应的对象而不是相应的属性。例如:即使现有的 pageContext 属性包含某些其他值,${pageContext} 也返回 PageContext 对象。

2、 注意 <%@ pageisELIgnored="true" %> 表示是否禁用EL语言,TRUE表示禁止.FALSE表示不禁止.JSP2.0中默认的启用EL语言。

..
发表在 jsp | Jsp EL已关闭评论

JSP & tomcat

设置jsp默认pageEncoding;windows->preference->myeclipse->files and editors->jsp->encoding  utf-8
设置jsp为编辑模式,没有预览界面:https://zhidao.baidu.com/question/581118605.html?qq-pf-to=pcqq.group
tomcat:多线程,每一个客户都会创建一个新的线程,线程之间互不影响。单例模式
单例模式:
饿汉模式:
       优点:确保一个类被调用的时候只创建一个对象,节省时间和内存
       缺点:只要加载到这个类,对象就会被创建,会造成资源浪费
懒汉模式:
       优点:确保一个类被调用的时候只创建一个对象,只有在调用的时候才生出对象,节省时间和内存
       缺点:实现比较复杂
1.Tomcat:免费的开源的轻量级的服务器,中小型企业常用
    bin:  startup.bat 和startup.sh(linux)   shutdown.bat和shutdown.sh
    conf:  server.xml  服务器配置文件 和 web.xml  项目配置
    lib: 常用类库
    logs: 运行日志文件
    webapps:放置运行的项目
    work:放置jsp编译后的class文件
2.Tomcat的lib目录,存放的jar不仅能被tomcat访问,还能被在tomcat上发布的web应用访问。
   JavaWeb应用的lib目录下的jar只能被当前web应用访问。
3.打包web应用: jar  cvf e:\TestWeb.war *.*
   解包web应用:jar xvf e:\TestWeb.war *.*
4.Cookie:位于请求头或者响应头
   a.浏览器第一次访问服务器,没有cookie,在服务器第一次应答时会对浏览器发送一个cookie.
      Cookie mcookie=new Cookie("username","tom");
      res.addCookie(mcookie);
   b.setMaxAge(0) 指定浏览器删除cookie
      setMaxAge(-1) 指定浏览器不保存cookie
  c.setPath(path)和setDomain(domain)  控制cookie的读写范围
      cookie.setPath("/");    //整个tomcat服务器的应用都能读到
      cookie.setPath("/app/");  //只有app应用能读取到
      cookie.setDomain(" .cat.com");  //只有域名为 .cat.com的应用能访问到。
7.不同web应用通讯:Tomcat中<Context=false>表示该应用无法获得其他web应用的ServletContext对象
8.避免并发:为保证Servlet能同时相应多个客户的请求,通过为每个请求分配一个工作线程。或者同步代码
9.JSP指令:
   1.一个完整的JSP页面是由普通的模板元素(html)、注释元素、指令元素、 脚本元素  、动作元素构成。
   2.指令标记、JSP动作标记统称为  jsp标记   。
   3.JSP页面的程序片中可以插入 html 标记。

4.当JSP页面的一个客户线程在执行  synchronized 方法时,其他客户必须等待。

jsp在执行过程中经过(  翻译)阶段,由web容器将之转换成java源代码

jsp在执行过程中经过(编译)阶段,会将java源码转换成class文件( b  )

   特点:
   1.Servlet:优点:业务逻辑处理很方便,写java代码方便
                     缺点:页面表现麻烦
   2.jsp:优点:页面表现方便                        //动态网页技术,动态生成网页数据,而不是动态效果的网页
             缺点:业务逻辑处理麻烦,
      两者通常结合使用。
  为什么说jsp是Servlet?
   因为jsp页面被访问时会被tomcat编译生成对应的java文件,java文件对应的类继承org.apache.jasper.runtime.HttpJspBase类
   而HttpJspBase又继承于HttpServlet.
  Jsp的执行过程:
     1.客户端发送以 .jsp结尾的请求(url)
     2.服务器接收请求后,会进行拦截(tomcat的web.xml),调用JspServlet类,处理jsp文件,生成对应的java文件和class文件(work文件夹下)
     3.tomcat会调用生成好的class文件生成html代码,返回给客户端
  web.xml关于jsp文件配置
   <%@ 指令名 属性="值"  %>   常见指令:page  include  taglib   编译指令,通知Servlet引擎处理消息
    errorPage="error.jsp"          //只能处理运行时错误,不能处理编译时的错误
    web.xml错误处理:
       <error-page>
     <error-code>404</error-code>
     <location>/error404.jsp</location>

</error-page>

   <% page method="doPost"  %>
   <%@ include file="文件绝对URL或相对URL" %>   静态包含,目标可是HTML或JSP,但不能是Servlet
      静态导入:1.把多个页面合成一个页面(编译成一个页面),不能有相同的变量。
                          2.执行效率相对较高
                          3.通常用户没有java代码页面
                          4.耦合性相对较高
   <jsp:include page="目标的绝对URL或相对URL"/>  动态包含  HTML、JSP(目标响应结果会被加到源组件)或Servlet都可以
   无论是静态还是动态包含,源组件和目标组件都共享请求范围内的共享数据。
     动态导入:1.分别生成各自的java文件和class文件,互不影响,可以有相同的变量
                         2.执行效率相对较低
                         3.通常用在java代码较多的页面
                         4.耦合性相对较低
  不能同一个页面,两次forward,类似servlet
10.声明:
   <% ! declar;declar;...  %>
  <%! int a=10,b,c; String d="ww"; %>   声明全局变量:不建议使用,因为Servlet中不建议声明全局变量
11.代码段:
   <% %>
  <% a++; %>
12.表达式:
  <%=a++%>
13.注释: <%--aaaa--%>        直接不会被编译,其他的注释写在jsp中会被编译(如html注释  <!--aa--->)
14.隐含对象:
    四大作用域
     request:
     session:
     application:最大作用域,全局共享信息
     pageContext:作用域最小,只作用于当前的页面;但可以通过pageContext获取其他八个作用域
     out:向客户端发送数据的对象(如html页面代码)
     response:  jsp中不推荐使用
     config:getInitParameter()和getInitParamterValues()   获取servlet的配置信息,但不建议在jsp用
     page:
     exception:使用<% page isErrorPage='true'%>
   路径问题:
     服务器根路径:http://localhost:8080/      D:\MainSoftWare\tomcat7\apache-tomcat-7.0.72\webapps
     项目根路径:http://localhost:8080/Demo/       D:\MainSoftWare\tomcat7\apache-tomcat-7.0.72\webapps\Demo
     String path = request.getContextPath();
    String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
    <base href="<%=basePath%>">           //base:默认在本页面所有的超链接和路径前面加项目的根路径
    <a href="index.jsp">path</a>              //http://localhost:8080/Demo/index.jsp
      req.getRequestDispather("/").forward(req,resp);      //请求转发   "/"  代表项目根路径  http://localhost:8080/Demo/
     resp.sendRedirect("/");        //重定向      "/" 代表服务器根路径   http://localhost:8080/
    <url-pattern>/index.jsp</url-pattern>  //  "/"代表项目的根路径
    1.相对路径:不能改变文件的相对位置
     2.绝对路径:不能修改项目的名称(推荐使用绝对路径)
15.请求转发    动作指令:jsp:forward、jsp:param等只是运行时的动作
   <jsp:forward  page="目标的绝对URL或相对URL"/>  请求转发之后的代码不会继续执行
   特点:执行forward时,用户请求的地址没有发生改变,但是请求的参数、属性不丢失
16.异常页:
     <%@ page errorPage="errorpage.jsp" %>  应先声明为异常页<% pageisErrorPage="true" %>
17.预编译:
    http://localhost:8080/app/hello.jsp?jsp_precompile=true
18.JNDI(负责将对象和名字绑定,对象工厂负责生产出对象):
   JDBC2.0开始提供javax.sql.DataSource,负责建立与数据库的链接,在程序中访问数据时
   不必编写连接数据库的代码,可以直接从数据源中获取数据库连接。
    Context:服务端:bind(String str,Object obj);      将对象与一个名字绑定
                            lookup(String name);      返回指定名字绑定的对象
   在META-INF下配置context.xml:
   <Context reloadable="true">
  <Resource name="jdbc/bookdb" auth="Container" type="javax.sql.DataSource"
          maxActive="100" maxIdle="30" maxWait="10000"
          username="root"  password="123456"
          driverClassName="com.mysql.jdbc.Driver"
          url="jdbc:mysql://localhost:3306/bookdb?autoReconnect=true"/>

</Context>

   并且在web.xml中配置:
   <web-app>
    <resource-ref>
          <description>MYSQLDB Connection</description>
          <res-ref-name>jdbc/bookdb</res-ref-name>
          <res-type>javax.sql.DataSource</res-type>
          <res-auth>Container</res-auth>
    </resource-ref>

</web-app>

   public BaseDao() throws Exception{
        //引入JNDI对象与名字绑定
        Context ctx=new InitialContext();
        if(null==ctx)
            throw new Exception("No Exception");
        ds=(DataSource) ctx.lookup("java:comp/env/jdbc/bookdb");

}

19.session会话:
  invalidate();   销毁当前的会话,Servlet容器释放HttpSession对象占用的资源
  cookie机制通常用于保存客户的状态信息,设置最大存活时间后,会保存到浏览器的硬盘,所以要求cookie的属性值必须是可序列化的
  Servlet容器创建新的HttpSession:
  a.一个浏览器进程第一次访问Web应用中支持会话中的任一个网页。
  b.当浏览器与web应用的一次会话已经被销毁后,浏览器进程再次访问web应用中的支持会话的任一个网页。
  JSP默认支持会话,HttpServlet默认不支持会话。
 response.encodeURL(url)   会在浏览器不支持会话的情况,使用URL支持会话。
 response.sendRedirect(response.encodeRedirectURL("mail.jsp"));  重定向时用
 Cookie:
  Cookie cookie=new Cookie("name","kkk");
  res.addCookie(cookie);
 cookie支持中文
 发送前先编码:
      java.net.URLEncoder.encode("书","utf-8");
  接收端解码:
     java.net.URLDecoder.decode(cookies[i].getValue(),"utf-8");
20.Tomcat会话管理:
   a.StandardManager:标准会话管理器。
   b.PersistentManager:更多会话管理功能。
   会话存储:
   FileStore:将HttpSession对象保存在一个文件中
   JDBCStore:将HttpSession对象保存在数据库的一张表中
21.会话监听:
 HttpSessionListener和HttpSessionAttributeListener,必须在web.xml中通过<listener>向Servlet容器注册。
23.EL表达式:
    优点:1.不用导包 2.简洁 3.如果参数没有传过来,则什么都不显示
    User里存Address对象
    EL表达式:$+{ }
       表达式获取参数信息
     <li><%=request.getParameter("uname") %></li>
     <li><%=request.getParameterValues("fav")[0] %></li>
     <li><%=request.getAttribute("realname") %></li>
     <li><%=((List<String>)request.getAttribute("list")).get(2) %></li>
     <li><%=((Map<String,String>)request.getAttribute("map")).get("CC") %> </li>
      <li><%=((User)request.getAttribute("user")).getAddress().getTown() %> </li>
     <li><%=((List<User>)request.getAttribute("userList")).get(2).getAddress().getTown() %> </li>
     <li><%=((Map<String,User>)request.getAttribute("userMap")).get("user3").getAddress().getTown() %> </li>
      EL获取请求参数信息
     <li>${param.uname }</li>
     <li>${paramValues.fav[0] }</li>             getParamter则需要param获取
     <li>${realname }</li>                              getAttribute直接获取属性
     <li>${list[2] }</li>
     <li>${map.CC }</li>
     <li>${user.address.town }</li>               address必须与User类中的address大小写一样
     <li>${userList[2].address.town }</li>
     <li>${userMap.user3.address.town }</li>
24.EL取值范围:
     1.el表达式取值默认从小到大取值(pageContext->request->session->application)
     2.pageScope: requestScope:sessionScope: applicationScope:
      导入fmt.tld文件
25. .和[]    访问一个bean属性或者Map entry        . 取值方便,[]功能强大
      ${user.name }    ${user["name"]}      ${user[name]}
      empty:用来对一个空变量值进行判断:null、一个空String、空Map、没有条目的Collection集合
      ${ empty name}
      +  作为算术符,加操作(但没有字符串相连的操作)
      ${1/0}   Infinity    ${ 1+"a"}  不能显示,结果为NaN      ${ 1+"1" }    2
26.JSTL: 替代在jsp中写java代码
       主要是get/set/remove    导入 <%@ taglib uri="http://java.sun.com/jsp/jstl/core  " prefix="s"%>
     1.<c:out value="${ name}"  default="zhansgan"> </c:out>
     2.<c:set var="name" value="kkk"  scope="session"></c:set>       //设置参数    ${ sessionScope.name }
     3.<c:remove var="name" >                ${sessionScope.name  }     //移除name就找不到值,默认移除全部
     4.<c:if test="${sex==1}">男</c:if>
     5.<c:choose>
            <c:when test="${sex==1}">男</c:when>
            <c:otherwise>其他</c:otherwise>
        </c:choose>
     6.<c:foreach  var="aa"  begin="1"  end="9"   step="3">           //类似java中的for
           ${aa}                                                                                          //每隔3个输出一次
        </c:foreach>
        <c:foreach  items="${list}" var="aa"  varStatus="vars" >
              ${aa}--${vars.first}--${vars.last}--${vars.index}                      //判断是否是list的第一个元素;index代表下标
        </c:foreach>
       <c:foreach items="${userList}"  var="aa">
              ${aa.name}--${aa.address.city}                 address存放于user里的另一个类
       </c:foreach>
Session:本质是一个哈希表,哈希表的key就是传递给浏览器的名为jessionid的Cookie值。
当一个值要保存到Session中,须有以下步骤:
(jessionid的Cookie值在浏览器关闭时会自动删除;或者将其MaxAge的值设为-1,也能达到浏览器关闭时自动删除目的)
   a.获取jsessionid的值,没有就调用request.getSession()生成
   b.得到session对象之后,通过setAttribute()往哈希表中写数据
   c.同时还可以通过getAttribute获取该属性值。
fail to load the jni shared library    由于jdk版本与eclipse位数版本不一致
Tomcat7路径:D:\MainSoftWare\tomcat7\apache-tomcat-7.0.72\webapps\ROOT
taglib definition not consistent with specification version  问题:http://www.ithao123.cn/content-37861.html
23.自定义标签: 继承SimpleTagSupport
    TLD:标签库定义
  taglib是根元素,一般包含三个元素:
      tlib-version:标签库实现的版本
      short-name:标签库短名
      uri:指定该标签库的唯一标识
  tag:包含下列子元素:
      name:标签的名称,jsp通过此名称来使用该标签
      tag-class:指定标签由哪个处理类来处理。
        body-content:指定标签体内容
<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
    version="2.0">
    <tlib-version>1.0</tlib-version>
    <short-name>SimpleTagLibrary</short-name>
    <uri>/jsp2-example-taglib.tld</uri>     //tld文件路径
    <tag>
       <name>MyFirstTLD</name>
       <tag-class>com.lzx.MyFirstTag</tag-class>
       <body-content>empty</body-content>
    </tag>
</taglib>
引用tld: <%@ taglib uri="/jsp2-example-taglib.tld" prefix="first" %>
                 <first:MyFirstTLD/>
24.定义带属性的标签:
   带属性需增加:<attribute>
                <name>ddd</name>
                <required>true</required>
                <fragment>true</fragment>
               </attribute>
来源:
https://blog.csdn.net/q2857864700/article/details/56676319
发表在 jsp | JSP & tomcat已关闭评论

Paxos

Paxos算法在分布式领域具有非常重要的地位。但是Paxos算法有两个比较明显的缺点:1.难以理解 2.工程实现更难。

网上有很多讲解Paxos算法的文章,但是质量参差不齐。看了很多关于Paxos的资料后发现,学习Paxos最好的资料是论文《Paxos Made Simple》,其次是中、英文版维基百科对Paxos的介绍。本文试图带大家一步步揭开Paxos神秘的面纱。

Paxos是什么

Paxos算法是基于消息传递且具有高度容错特性一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品

虽然Mike Burrows说得有点夸张,但是至少说明了Paxos算法的地位。然而,Paxos算法也因为晦涩难懂而臭名昭著。本文的目的就是带领大家深入浅出理解Paxos算法,不仅理解它的执行流程,还要理解算法的推导过程,作者是怎么一步步想到最终的方案的。只有理解了推导过程,才能深刻掌握该算法的精髓。而且理解推导过程对于我们的思维也是非常有帮助的,可能会给我们带来一些解决问题的思路,对我们有所启发。

问题产生的背景

在常见的分布式系统中,总会发生诸如机器宕机网络异常(包括消息的延迟、丢失、重复、乱序,还有网络分区)等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,并且保证不论发生以上任何异常,都不会破坏整个系统的一致性。

注:这里某个数据的值并不只是狭义上的某个数,它可以是一条日志,也可以是一条命令(command)。。。根据应用场景不同,某个数据的值有不同的含义。

相关概念

在Paxos算法中,有三种角色:

  • Proposer
  • Acceptor
  • Learners

在具体的实现中,一个进程可能同时充当多种角色。比如一个进程可能既是Proposer又是Acceptor又是Learner

还有一个很重要的概念叫提案(Proposal)。最终要达成一致的value就在提案里。

注:

  • 暂且认为『提案=value』,即提案只包含value。在我们接下来的推导过程中会发现如果提案只包含value,会有问题,于是我们再对提案重新设计
  • 暂且认为『Proposer可以直接提出提案』。在我们接下来的推导过程中会发现如果Proposer直接提出提案会有问题,需要增加一个学习提案的过程。

Proposer可以提出(propose)提案;Acceptor可以接受(accept)提案;如果某个提案被选定(chosen),那么该提案里的value就被选定了。

回到刚刚说的『对某个数据的值达成一致』,指的是Proposer、Acceptor、Learner都认为同一个value被选定(chosen)。那么,Proposer、Acceptor、Learner分别在什么情况下才能认为某个value被选定呢?

  • Proposer:只要Proposer发的提案被Acceptor接受(刚开始先认为只需要一个Acceptor接受即可,在推导过程中会发现需要半数以上的Acceptor同意才行),Proposer就认为该提案里的value被选定了。
  • Acceptor:只要Acceptor接受了某个提案,Acceptor就任务该提案里的value被选定了。
  • Learner:Acceptor告诉Learner哪个value被选定,Learner就认为那个value被选定。

问题描述

假设有一组可以提出(propose)value(value在提案Proposal里)的进程集合。一个一致性算法需要保证提出的这么多value中,只有一个value被选定(chosen)。如果没有value被提出,就不应该有value被选定。如果一个value被选定,那么所有进程都应该能学习(learn)到这个被选定的value。对于一致性算法,安全性(safaty)要求如下:

  • 只有被提出的value才能被选定。
  • 只有一个value被选定,并且
  • 如果某个进程认为某个value被选定了,那么这个value必须是真的被选定的那个。

我们不去精确地定义其活性(liveness)要求。我们的目标是保证最终有一个提出的value被选定。当一个value被选定后,进程最终也能学习到这个value。

Paxos的目标:保证最终有一个value会被选定,当value被选定后,进程最终也能获取到被选定的value。

假设不同角色之间可以通过发送消息来进行通信,那么:

  • 每个角色以任意的速度执行,可能因出错而停止,也可能会重启。一个value被选定后,所有的角色可能失败然后重启,除非那些失败后重启的角色能记录某些信息,否则等他们重启后无法确定被选定的值。
  • 消息在传递过程中可能出现任意时长的延迟,可能会重复,也可能丢失。但是消息不会被损坏,即消息内容不会被篡改(拜占庭将军问题)。

推导过程

最简单的方案——只有一个Acceptor

假设只有一个Acceptor(可以有多个Proposer),只要Acceptor接受它收到的第一个提案,则该提案被选定,该提案里的value就是被选定的value。这样就保证只有一个value会被选定。

但是,如果这个唯一的Acceptor宕机了,那么整个系统就无法工作了!

因此,必须要有多个Acceptor

多个Acceptor

多个Acceptor的情况如下图。那么,如何保证在多个Proposer和多个Acceptor的情况下选定一个value呢?

下面开始寻找解决方案。

如果我们希望即使只有一个Proposer提出了一个value,该value也最终被选定。

那么,就得到下面的约束:

P1:一个Acceptor必须接受它收到的第一个提案。

但是,这又会引出另一个问题:如果每个Proposer分别提出不同的value,发给不同的Acceptor。根据P1,Acceptor分别接受自己收到的value,就导致不同的value被选定。出现了不一致。如下图:

刚刚是因为『一个提案只要被一个Acceptor接受,则该提案的value就被选定了』才导致了出现上面不一致的问题。因此,我们需要加一个规定:

规定:一个提案被选定需要被半数以上的Acceptor接受

这个规定又暗示了:『一个Acceptor必须能够接受不止一个提案!』不然可能导致最终没有value被选定。比如上图的情况。v1、v2、v3都没有被选定,因为它们都只被一个Acceptor的接受。

最开始讲的『提案=value』已经不能满足需求了,于是重新设计提案,给每个提案加上一个提案编号,表示提案被提出的顺序。令『提案=提案编号+value』。

虽然允许多个提案被选定,但必须保证所有被选定的提案都具有相同的value值。否则又会出现不一致。

于是有了下面的约束:

P2:如果某个value为v的提案被选定了,那么每个编号更高的被选定提案的value必须也是v。

一个提案只有被Acceptor接受才可能被选定,因此我们可以把P2约束改写成对Acceptor接受的提案的约束P2a。

P2a:如果某个value为v的提案被选定了,那么每个编号更高的被Acceptor接受的提案的value必须也是v。

只要满足了P2a,就能满足P2。

但是,考虑如下的情况:假设总的有5个Acceptor。Proposer2提出[M1,V1]的提案,Acceptor2~5(半数以上)均接受了该提案,于是对于Acceptor2~5和Proposer2来讲,它们都认为V1被选定。Acceptor1刚刚从宕机状态恢复过来(之前Acceptor1没有收到过任何提案),此时Proposer1向Acceptor1发送了[M2,V2]的提案(V2≠V1且M2>M1),对于Acceptor1来讲,这是它收到的第一个提案。根据P1(一个Acceptor必须接受它收到的第一个提案。),Acceptor1必须接受该提案!同时Acceptor1认为V2被选定。这就出现了两个问题:

  1. Acceptor1认为V2被选定,Acceptor2~5和Proposer2认为V1被选定。出现了不一致。
  2. V1被选定了,但是编号更高的被Acceptor1接受的提案[M2,V2]的value为V2,且V2≠V1。这就跟P2a(如果某个value为v的提案被选定了,那么每个编号更高的被Acceptor接受的提案的value必须也是v)矛盾了。

所以我们要对P2a约束进行强化!

P2a是对Acceptor接受的提案约束,但其实提案是Proposer提出来的,所有我们可以对Proposer提出的提案进行约束。得到P2b:

P2b:如果某个value为v的提案被选定了,那么之后任何Proposer提出的编号更高的提案的value必须也是v。

由P2b可以推出P2a进而推出P2。

那么,如何确保在某个value为v的提案被选定后,Proposer提出的编号更高的提案的value都是v呢?

只要满足P2c即可:

P2c:对于任意的N和V,如果提案[N, V]被提出,那么存在一个半数以上的Acceptor组成的集合S,满足以下两个条件中的任意一个:

  • S中每个Acceptor都没有接受过编号小于N的提案。
  • S中Acceptor接受过的最大编号的提案的value为V。

Proposer生成提案

为了满足P2b,这里有个比较重要的思想:Proposer生成提案之前,应该先去『学习』已经被选定或者可能被选定的value,然后以该value作为自己提出的提案的value。如果没有value被选定,Proposer才可以自己决定value的值。这样才能达成一致。这个学习的阶段是通过一个『Prepare请求』实现的。

于是我们得到了如下的提案生成算法

  1. Proposer选择一个新的提案编号N,然后向某个Acceptor集合(半数以上)发送请求,要求该集合中的每个Acceptor做出如下响应(response)。

(a) 向Proposer承诺保证不再接受任何编号小于N的提案

(b) 如果Acceptor已经接受过提案,那么就向Proposer响应已经接受过的编号小于N的最大编号的提案

我们将该请求称为编号为NPrepare请求

  1. 如果Proposer收到了半数以上的Acceptor的响应,那么它就可以生成编号为N,Value为V的提案[N,V]。这里的V是所有的响应中编号最大的提案的Value。如果所有的响应中都没有提案,那 么此时V就可以由Proposer自己选择
    生成提案后,Proposer将该提案发送给半数以上的Acceptor集合,并期望这些Acceptor能接受该提案。我们称该请求为Accept请求。(注意:此时接受Accept请求的Acceptor集合不一定是之前响应Prepare请求的Acceptor集合)

Acceptor接受提案

Acceptor可以忽略任何请求(包括Prepare请求和Accept请求)而不用担心破坏算法的安全性。因此,我们这里要讨论的是什么时候Acceptor可以响应一个请求。

我们对Acceptor接受提案给出如下约束:

P1a:一个Acceptor只要尚未响应过任何编号大于NPrepare请求,那么他就可以接受这个编号为N的提案

如果Acceptor收到一个编号为N的Prepare请求,在此之前它已经响应过编号大于N的Prepare请求。根据P1a,该Acceptor不可能接受编号为N的提案。因此,该Acceptor可以忽略编号为N的Prepare请求。当然,也可以回复一个error,让Proposer尽早知道自己的提案不会被接受。

因此,一个Acceptor只需记住:1. 已接受的编号最大的提案 2. 已响应的请求的最大编号。

Paxos算法描述

经过上面的推导,我们总结下Paxos算法的流程。

Paxos算法分为两个阶段。具体如下:

  • 阶段一:

(a) Proposer选择一个提案编号N,然后向半数以上的Acceptor发送编号为N的Prepare请求

(b) 如果一个Acceptor收到一个编号为N的Prepare请求,且N大于该Acceptor已经响应过的所有Prepare请求的编号,那么它就会将它已经接受过的编号最大的提案(如果有的话)作为响应反馈给Proposer,同时该Acceptor承诺不再接受任何编号小于N的提案

  • 阶段二:

(a) 如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应,那么它就会发送一个针对[N,V]提案Accept请求半数以上的Acceptor。注意:V就是收到的响应编号最大的提案的value,如果响应中不包含任何提案,那么V就由Proposer自己决定

(b) 如果Acceptor收到一个针对编号为N的提案的Accept请求,只要该Acceptor没有对编号大于NPrepare请求做出过响应,它就接受该提案

Learner学习被选定的value

Learner学习(获取)被选定的value有如下三种方案:

如何保证Paxos算法的活性

通过选取主Proposer,就可以保证Paxos算法的活性。至此,我们得到一个既能保证安全性,又能保证活性分布式一致性算法——Paxos算法

参考资料

  • 论文《Paxos Made Simple》
  • 论文《The Part-Time Parliament》
  • 英文版维基百科的Paxos
  • 中文版维基百科的Paxos
  • 书籍《从Paxos到ZooKeeper》

 

原文:

https://www.cnblogs.com/linbingdong/p/6253479.html

 

... END ...

 

发表在 consensus | Paxos已关闭评论

Raft算法

过去, Paxos一直是分布式协议的标准,但是Paxos难于理解,更难以实现,Google的分布式锁系统Chubby作为Paxos实现曾经遭遇到很多坑。

来自Stanford的新的分布式协议研究称为Raft,它是一个为真实世界应用建立的协议,主要注重协议的落地性和可理解性。

在了解Raft之前,我们先了解Consensus一致性这个概念,它是指多个服务器在状态达成一致,但是在一个分布式系统中,因为各种意外可能,有的服务器可能会崩溃或变得不可靠,它就不能和其他服务器达成一致状态。这样就需要一种Consensus协议,一致性协议是为了确保容错性,也就是即使系统中有一两个服务器当机,也不会影响其处理过程。

为了以容错方式达成一致,我们不可能要求所有服务器100%都达成一致状态,只要超过半数的大多数服务器达成一致就可以了,假设有N台服务器,N/2 +1 就超过半数,代表大多数了。

Paxos和Raft都是为了实现Consensus一致性这个目标,这个过程如同选举一样,参选者需要说服大多数选民(服务器)投票给他,一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。

在Raft中,任何时候一个服务器可以扮演下面角色之一:

  1. Leader: 处理所有客户端交互,日志复制等,一般一次只有一个Leader.
  2. Follower: 类似选民,完全被动
  3. Candidate候选人: 类似Proposer律师,可以被选为一个新的领导人。

Raft阶段分为两个,首先是选举过程,然后在选举出来的领导人带领进行正常操作,比如日志复制等。下面用图示展示这个过程:

1. 任何一个服务器都可以成为一个候选者Candidate,它向其他服务器Follower发出要求选举自己的请求:

2. 其他服务器同意了,发出OK。

注意如果在这个过程中,有一个Follower当机,没有收到请求选举的要求,因此候选者可以自己选自己,只要达到N/2 + 1 的大多数票,候选人还是可以成为Leader的。

3. 这样这个候选者就成为了Leader领导人,它可以向选民也就是Follower们发出指令,比如进行日志复制。

4. 以后通过心跳进行日志复制的通知

5. 如果一旦这个Leader当机崩溃了,那么Follower中有一个成为候选者,发出邀票选举。

6. Follower同意后,其成为Leader,继续承担日志复制等指导工作:

 

值得注意的是,整个选举过程是有一个时间限制的,如下图:

Splite Vote是因为如果同时有两个候选人向大家邀票,这时通过类似加时赛来解决,两个候选者在一段timeout比如300ms互相不服气的等待以后,因为双方得到的票数是一样的,一半对一半,那么在300ms以后,再由这两个候选者发出邀票,这时同时的概率大大降低,那么首先发出邀票的的候选者得到了大多数同意,成为领导者Leader,而另外一个候选者后来发出邀票时,那些Follower选民已经投票给第一个候选者,不能再投票给它,它就成为落选者了,最后这个落选者也成为普通Follower一员了。

 

日志复制

下面以日志复制为例子说明Raft算法,假设Leader领导人已经选出,这时客户端发出增加一个日志的要求,比如日志是"sally":

2. Leader要求Followe遵从他的指令,都将这个新的日志内容追加到他们各自日志中:

3.大多数follower服务器将日志写入磁盘文件后,确认追加成功,发出Commited Ok:

4. 在下一个心跳heartbeat中,Leader会通知所有Follwer更新commited 项目。

对于每个新的日志记录,重复上述过程。

如果在这一过程中,发生了网络分区或者网络通信故障,使得Leader不能访问大多数Follwers了,那么Leader只能正常更新它能访问的那些Follower服务器,而大多数的服务器Follower因为没有了Leader,他们重新选举一个候选者作为Leader,然后这个Leader作为代表于外界打交道,如果外界要求其添加新的日志,这个新的Leader就按上述步骤通知大多数Followers,如果这时网络故障修复了,那么原先的Leader就变成Follower,在失联阶段这个老Leader的任何更新都不能算commit,都回滚,接受新的Leader的新的更新。

总结:目前几乎所有语言都已经有支持Raft算法的库包,具体可参考:raftconsensus.github.io

 

原文:

https://www.jdon.com/artichect/raft.html

 

... END ...

 

发表在 consensus | Raft算法已关闭评论

ByteBuffer

概述

ByteBuffer是NIO里用得最多的Buffer,它包含两个实现方式:HeapByteBuffer是基于Java堆的实现,而DirectByteBuffer则使用了unsafe的API进行了堆外的实现。这里只说HeapByteBuffer。

使用

ByteBuffer最核心的方法是put(byte)get()。分别是往ByteBuffer里写一个字节,和读一个字节。

值得注意的是,ByteBuffer的读写模式是分开的,正常的应用场景是:往ByteBuffer里写一些数据,然后flip(),然后再读出来。

这里插两个Channel方面的对象,以便更好的理解Buffer。

ReadableByteChannel是一个从Channel中读取数据,并保存到ByteBuffer的接口,它包含一个方法:

public intread(ByteBuffer dst) throwsIOException;

WritableByteChannel则是从ByteBuffer中读取数据,并输出到Channel的接口:

public intwrite(ByteBuffer src) throwsIOException;

那么,一个ByteBuffer的使用过程是这样的:

1. byteBuffer = ByteBuffer.allocate(N);    //创建

2. readableByteChannel.read(byteBuffer);   //读取数据,写入byteBuffer

3. byteBuffer.flip();              //变读为写

4. writableByteChannel.write(byteBuffer);   //读取byteBuffer,写入数据

看到这里,一般都不太明白flip()干了什么事,先从ByteBuffer结构说起:

 

ByteBuffer的创建和读写

 

1. ByteBuffer定义了4个static方法来做创建工作:

ByteBuffer allocate(int capacity) //创建一个指定capacity的ByteBuffer。
ByteBuffer allocateDirect(int capacity) //创建一个direct的ByteBuffer,这样的ByteBuffer在参与IO操作时性能会更好
ByteBuffer wrap(byte [] array)
ByteBuffer wrap(byte [] array, int offset, int length) //把一个byte数组或byte数组的一部分包装成ByteBuffer。

2. ByteBuffer定义了一系列get和put操作来从中读写byte数据,如下面几个:
byte get()
ByteBuffer get(byte [] dst)
byte get(int index)
ByteBuffer put(byte b)
ByteBuffer put(byte [] src)
ByteBuffer put(int index, byte b)
这些操作可分为绝对定位和相对定为两种,相对定位的读写操作依靠position来定位Buffer中的位置,并在操
作完成后会更新position的值。在其它类型的buffer中,也定义了相同的函数来读写数据,唯一不同的就是一
些参数和返回值的类型。

3. 除了读写byte类型数据的函数,ByteBuffer的一个特别之处是它还定义了读写其它primitive数据的方法,如:

int getInt()             //从ByteBuffer中读出一个int值。
ByteBuffer putInt(int value)  // 写入一个int值到ByteBuffer中。

3.1 字节序

读写其它类型的数据牵涉到字节序问题,ByteBuffer会按其字节序(大字节序或小字节序)写入或读出一个其它
类型的数据(int,long…)。字节序可以用order方法来取得和设置:
ByteOrder order() //返回ByteBuffer的字节序。
ByteBuffer order(ByteOrder bo)   // 设置ByteBuffer的字节序。

3.2 ByteOrder
用来表示ByteBuffer字节序的类,可将其看成java中的enum类型。主要定义了下面几个static方法和属性:
ByteOrder BIG_ENDIAN       代表大字节序的ByteOrder。
ByteOrder LITTLE_ENDIAN 代表小字节序的ByteOrder。
ByteOrder nativeOrder()       返回当前硬件平台的字节序。

 

4. ByteBuffer另一个特别的地方是可以在它的基础上得到其它类型的buffer。如:
CharBuffer asCharBuffer()
为当前的ByteBuffer创建一个CharBuffer的视图。在该视图buffer中的读写操作会按照ByteBuffer的字节
序作用到ByteBuffer中的数据上。

用这类方法创建出来的buffer会从ByteBuffer的position位置开始到limit位置结束,可以看作是这段数据
的视图。视图buffer的readOnly属性和direct属性与ByteBuffer的一致,而且也只有通过这种方法,才可
以得到其他数据类型的direct buffer。

ByteBuffer内部字段

byte[] buff

buff即内部用于缓存的数组。

position

当前读取的位置。

读/写操作的当前下标。当使用buffer的相对位置进行读/写操作时,读/写会从这个下标进行,并在操作完成后,
buffer会更新下标的值。

mark

为某一读过的位置做标记,便于某些时候回退到该位置。

一个临时存放的位置下标。调用mark()会将mark设为当前的position的值,以后调用reset()会将position属性设
置为mark的值。mark的值总是小于等于position的值,如果将position的值设的比mark小,当前的mark值会被抛弃掉。

capacity

初始化时候的容量。

这个Buffer最多能放多少数据。capacity一般在buffer被创建的时候指定。

limit

在Buffer上进行的读写操作都不能越过这个下标。当写数据到buffer中时,limit一般和capacity相等,当读数据时,
limit代表buffer中有效数据的长度。

读写的上限,limit<=capacity。

 

这些属性总是满足以下条件:
0 <= mark <= position <= limit <= capacity

limit和position的值除了通过limit()和position()函数来设置,也可以通过下面这些函数来改变:

Buffer clear()
把position设为0,把limit设为capacity,一般在把数据写入Buffer前调用。

Buffer flip()
把limit设为当前position,把position设为0,一般在从Buffer读出数据前调用。

Buffer rewind()
把position设为0,limit不变,一般在把数据重写入Buffer前调用。

compact()

该方法的作用是将 position 与 limit之间的数据复制到buffer的开始位置,复制后 position  = limit -position,limit = capacity

但如果position 与limit 之间没有数据的话发,就不会进行复制  详细参考:java nio Buffer 中 compact的作用

mark()与reset()方法

  通过调用Buffer.mark()方法,可以标记Buffer中的一个特定position。之后可以通过调用Buffer.reset()方法恢复到这个position。例如:

1.buffer.mark();

2.//call buffer.get() a couple of times, e.g. during parsing.

3.buffer.reset(); //set position back to mark

equals()与compareTo()方法

  可以使用equals()和compareTo()方法两个Buffer。

  equals()

  当满足下列条件时,表示两个Buffer相等:

  1. 有相同的类型(byte、char、int等)。
  2. Buffer中剩余的byte、char等的个数相等。
  3. Buffer中所有剩余的byte、char等都相同。

如你所见,equals只是比较Buffer的一部分,不是每一个在它里面的元素都比较。实际上,它只比较Buffer中的剩余元素。

  compareTo()方法

  compareTo()方法比较两个Buffer的剩余元素(byte、char等), 如果满足下列条件,则认为一个Buffer“小于”另一个Buffer:

    1. 第一个不相等的元素小于另一个Buffer中对应的元素 。
    2. 所有元素都相等,但第一个Buffer比另一个先耗尽(第一个Buffer的元素个数比另一个少)。

Buffer对象有可能是只读的,这时,任何对该对象的写操作都会触发一个ReadOnlyBufferException。
isReadOnly()方法可以用来判断一个Buffer是否只读。

 

图解

put

写模式下,往buffer里写一个字节,并把postion移动一位。写模式下,一般limit与capacity相等。

flip

写完数据,需要开始读的时候,将postion复位到0,并将limit设为当前postion。

get

从buffer里读一个字节,并把postion移动一位。上限是limit,即写入数据的最后位置。

clear

将position置为0,并不清除buffer内容。

mark相关的方法主要是mark()(标记)和reset()(回到标记)

 

.

原文: https://www.cnblogs.com/ruber/p/6857159.html

 

 

发表在 java | ByteBuffer已关闭评论

[netty] ByteBuf

netty 中的 ByteBuf 默认是使用 big-endian
一、创建
1、池化创建 ByteBufAllocator
获取ByteBufAllocator
Channel channel = ...;
ByteBufAllocator allocator = channel.alloc();
//1....ChannelHandlerContext ctx = ...;
ByteBufAllocator allocator2 = ctx.alloc();
//2
ByteBufAllocator中创建byteBuf的方法
名称
描述
buffer() buffer(int) buffer(int, int)
Return a ByteBuf with heap-based or direct data storage.
heapBuffer() heapBuffer(int) heapBuffer(int, int)
Return a ByteBuf with heap-based storage.
directBuffer() directBuffer(int) directBuffer(int, int)
Return a ByteBuf with direct storage.
compositeBuffer() compositeBuffer(int) heapCompositeBuffer() heapCompositeBuffer(int) directCompositeBuffer()directCompositeBuffer(int)
Return a CompositeByteBuf that can be expanded by adding heapbased or direct buffers.
ioBuffer()
Return a ByteBuf that will be used for I/O operations on a socket.
2、Unpooled (非池化)缓存
当未引用 ByteBufAllocator 时,上面的方法无法访问到 ByteBuf。对于这个用例 Netty 提供一个实用工具类称为 Unpooled,,它提供了静态辅助方法来创建非池化的 ByteBuf 实例。表5.9列出了最重要的方法
Table 5.9 Unpooled helper class
名称
描述
buffer() buffer(int) buffer(int, int)
Returns an unpooled ByteBuf with heap-based storage
directBuffer() directBuffer(int) directBuffer(int, int)
Returns an unpooled ByteBuf with direct storage
wrappedBuffer()
Returns a ByteBuf, which wraps the given data.
copiedBuffer()
Returns a ByteBuf, which copies the given data
在 非联网项目,该 Unpooled 类也使得它更容易使用的 ByteBuf API,获得一个高性能的可扩展缓冲 API,
3、ByteBufUtil创建 (ByteBufUtil中有很多操作buf的API)
二、读 get/read get不会改变读索引,read会改变读索引
getBoolean(int)
返回当前索引的 Boolean 值
getByte(int) getUnsignedByte(int)
返回当前索引的(无符号)字节
getMedium(int) getUnsignedMedium(int)
返回当前索引的 (无符号) 24-bit 中间值
getInt(int) getUnsignedInt(int)
返回当前索引的(无符号) 整型
getLong(int) getUnsignedLong(int)
返回当前索引的 (无符号) Long 型
getShort(int) getUnsignedShort(int)
返回当前索引的 (无符号) Short 型
getBytes(int, ...)
字节
方法名称
描述
readBoolean()
 返回当前索引的Boolean值,读索引加一
readByte()
readUnsignedByte()
返回当前索引的(无符号)字节,读索引加一
readMedium()
readUnsignedMedium()
返回当前索引的 (无符号) 24-bit 中间值,读索引加3
readInt()
readUnsignedInt()
 返回当前索引的(无符号) 整型,读索引加4
readLong()
readUnsignedLong()
 返回当前索引的 (无符号) Long 型,读索引加8
readShort()
readUnsignedShort()
返回当前索引的 (无符号) Short 型,读索引加2
readBytes(int,int, ...)
、放回当前位置到length
得一个字节数组,读索引加length
三、写操作 set/write
方法名称
描述
setBoolean(int, boolean)
在指定的索引位置设置 Boolean 值
setByte(int, int)
在指定的索引位置设置 byte 值
setMedium(int, int)
在指定的索引位置设置 24-bit 中间 值
setInt(int, int)
在指定的索引位置设置 int 值
setLong(int, long)
在指定的索引位置设置 long 值
setShort(int, int)
在指定的索引位置设置 short 值
方法名称
描述
writeBoolean(boolean)
在指定的索引位置设置 Boolean 值,写索引加一
writeByte(int)
在指定的索引位置设置 byte 值,写索引加一
writeMedium(int)
在指定的索引位置设置 24-bit 中间 值,写索引加3
writeInt(int)
在指定的索引位置设置 int 值,写索引加4
writeLong(long)
在指定的索引位置设置 long 值,写索引加8
writeShort(int)
在指定的索引位置设置 short 值,写索引加2
writeBytes(int,...)
 在当前索引写入一个Byte数组,写索引加数组长度
四、索引管理
markReaderIndex(),
 markWriterIndex()
标记读(写)索引
resetReaderIndex()
resetWriterIndex()
读(写)索引回到mark标记的索引值
readerIndex(int)
 writerIndex(int)
将读(写)索引设置到指定位置
clear()
可以同时设置 readerIndex 和 writerIndex 为 0。这不会清除内存中的内容
五、查找
forEachByte(ByteBufProcessor.FIND_NUL)
查找byte,返回byte的索引
六、副本
duplicate()
slice()
slice(int, int)
readOnly(),
order(ByteOrder)
所有这些都返回一个新的 ByteBuf 实例包括它自己的 reader, writer 和标记索引。然而,内部数据存储共享就像在一个 NIO 的 ByteBuffer
 copy()
 copy(int, int)
返回的 ByteBuf 有数据的独立副本。
七、其他
方法名称
描述
isReadable()
返回是否有字节可读
isWritable()
返回是否可以写
readableBytes()
返回可以读的字节长度
writablesBytes()
返回可以写的字节场地
capacity()
返回byteBuf的容量
maxCapacity()
返回byteBuf可以有的最大容量
hasArray()
如果byteBuf可以直接返回一个数组就返回true
(heap buf才会为true)
array()
hasArray返回true,该方法就会返回一个数组
.
发表在 java | 标签为 | [netty] ByteBuf已关闭评论