|
#
Linux is a powerhouse when it comes to networking, and provides a full featured and high performance network stack. When combined with web front-ends such asHAProxy, lighttpd, Nginx, Apache or your favorite application server, Linux is a killer platform for hosting web applications. Keeping these applications up and operational can sometimes be a challenge, especially in this age of horizontally scaled infrastructure and commodity hardware. But don't fret, since there are a number of technologies that can assist with making your applications and network infrastructure fault tolerant. One of these technologies, keepalived, provides interface failover and the ability to perform application-layer health checks. When these capabilities are combined with the Linux Virtual Server (LVS) project, a fault in an application will be detected by keepalived, and the virtual interfaces that are accessed by clients can be migrated to another available node. This article will provide an introduction to keepalived, and will show how to configure interface failover between two or more nodes. Additionally, the article will show how to debug problems with keepalived and VRRP. What Is Keepalived?
The keepalived project provides a keepalive facility for Linux servers. This keepalive facility consists of a VRRP implementation to manage virtual routers (aka virtual interfaces), and a health check facility to determine if a service (web server, samba server, etc.) is up and operational. If a service fails a configurable number of health checks, keepalived will fail a virtual router over to a secondary node. While useful in its own right, keepalived really shines when combined with the Linux Virtual Server project. This article will focus on keepalived, and a future article will show how to integrate the two to create a fault tolerant load-balancer. Installing KeepAlived From Source Code
Before we dive into configuring keepalived, we need to install it. Keepalived is distributed as source code, and is available in several package repositories. To install from source code, you can execute wget or curl to retrieve the source, and then run "configure", "make" and "make install" compile and install the software: $ wget http://www.keepalived.org/software/keepalived-1.1.17.tar.gz $ tar xfvz keepalived-1.1.17.tar.gz $ cd keepalived-1.1.17 $ ./configure --prefix=/usr/local $ make && make install In the example above, the keepalived daemon will be compiled and installed as /usr/local/sbin/keepalived. Configuring KeepAlived
The keepalived daemon is configured through a text configuration file, typically named keepalived.conf. This file contains one or more configuration stanzas, which control notification settings, the virtual interfaces to manage, and the health checks to use to test the services that rely on the virtual interfaces. Here is a sample annotated configuration that defines two virtual IP addresses to manage, and the individuals to contact when a state transition or fault occurs: # Define global configuration directives global_defs { # Send an e-mail to each of the following # addresses when a failure occurs notification_email { matty@prefetch.net operations@prefetch.net } # The address to use in the From: header notification_email_from root@VRRP-director1.prefetch.net # The SMTP server to route mail through smtp_server mail.prefetch.net # How long to wait for the mail server to respond smtp_connect_timeout 30 # A descriptive name describing the router router_id VRRP-director1 } # Create a VRRP instance VRRP_instance VRRP_ROUTER1 { # The initial state to transition to. This option isn't # really all that valuable, since an election will occur # and the host with the highest priority will become # the master. The priority is controlled with the priority # configuration directive. state MASTER # The interface keepalived will manage interface br0 # The virtual router id number to assign the routers to virtual_router_id 100 # The priority to assign to this device. This controls # who will become the MASTER and BACKUP for a given # VRRP instance. priority 100 # How many seconds to wait until a gratuitous arp is sent garp_master_delay 2 # How often to send out VRRP advertisements advert_int 1 # Execute a notification script when a host transitions to # MASTER or BACKUP, or when a fault occurs. The arguments # passed to the script are: # $1 - "GROUP"|"INSTANCE" # $2 = name of group or instance # $3 = target state of transition # Sample: VRRP-notification.sh VRRP_ROUTER1 BACKUP 100 notify "/usr/local/bin/VRRP-notification.sh" # Send an SMTP alert during a state transition smtp_alert # Authenticate the remote endpoints via a simple # username/password combination authentication { auth_type PASS auth_pass 192837465 } # The virtual IP addresses to float between nodes. The # label statement can be used to bring an interface # online to represent the virtual IP. virtual_ipaddress { 192.168.1.100 label br0:100 192.168.1.101 label br0:101 } } The configuration file listed above is self explanatory, so I won't go over each directive in detail. I will point out a couple of items: - Each host is referred to as a director in the documentation, and each director can be responsible for one or more VRRP instances
- Each director will need its own copy of the configuration file, and the router_id, priority, etc. should be adjusted to reflect the nodes name and priority relative to other nodes
- To force a specific node to master a virtual address, make sure the director's priority is higher than the other virtual routers
- If you have multiple VRRP instances that need to failover together, you will need to add each instance to a VRRP_sync_group
- The notification script can be used to generate custom syslog messages, or to invoke some custom logic (e.g., restart an app) when a state transition or fault occurs
- The keepalived package comes with numerous configuration examples, which show how to configure numerous aspects of the server
Starting Keepalived
Keepalived can be executed from an RC script, or started from the command line. The following example will start keepalived using the configuration file /usr/local/etc/keepalived.conf: $ keepalived -f /usr/local/etc/keepalived.conf If you need to debug keepalived issues, you can run the daemon with the "--dont-fork", "--log-console" and "--log-detail" options: $ keepalived -f /usr/local/etc/keepalived.conf --dont-fork --log-console --log-detail These options will stop keepalived from fork'ing, and will provide additional logging data. Using these options is especially useful when you are testing out new configuration directives, or debugging an issue with an existing configuration file. Locating The Router That is Managing A Virtual IP
To see which director is currently the master for a given virtual interface, you can check the output from the ip utility: VRRP-director1$ ip addr list br0 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/24 brd 192.168.1.255 scope global br0 inet 192.168.1.100/32 scope global br0:100 inet 192.168.1.101/32 scope global br0:101 inet6 fe80::224:8cff:fe4e:7f6/64 scope link valid_lft forever preferred_lft forever VRRP-director2$ ip addr list br0 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.7/24 brd 192.168.1.255 scope global br0 inet6 fe80::224:8cff:fe4e:7f6/64 scope link valid_lft forever preferred_lft forever In the output above, we can see that the virtual interfaces 192.168.1.100 and 192.168.1.101 are currently active on VRRP-director1. Troubleshooting Keepalived And VRRP
The keepalived daemon will log to syslog by default. Log entries will range from entries that show when the keepalive daemon started, to entries that show state transitions. Here are a few sample entries that show keepalived starting up, and the node transitioning a VRRP instance to the MASTER state: Jul 3 16:29:56 disarm Keepalived: Starting Keepalived v1.1.17 (07/03,2009) Jul 3 16:29:56 disarm Keepalived: Starting VRRP child process, pid=1889 Jul 3 16:29:56 disarm Keepalived_VRRP: Using MII-BMSR NIC polling thread... Jul 3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink reflector Jul 3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink command channel Jul 3 16:29:56 disarm Keepalived_VRRP: Registering gratutious ARP shared channel Jul 3 16:29:56 disarm Keepalived_VRRP: Opening file '/usr/local/etc/keepalived.conf'. Jul 3 16:29:56 disarm Keepalived_VRRP: Configuration is using : 62990 Bytes Jul 3 16:29:57 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Transition to MASTER STATE Jul 3 16:29:58 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Entering MASTER STATE Jul 3 16:29:58 disarm Keepalived_VRRP: Netlink: skipping nl_cmd msg... If you are unable to determine the source of a problem with the system logs, you can use tcpdump to display the VRRP advertisements that are sent on the local network. Advertisements are sent to a reserved VRRP multicast address (224.0.0.18), so the following filter can be used to display all VRRP traffic that is visible on the interface passed to the "-i" option: $ tcpdump -vvv -n -i br0 host 224.0.0.18 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 10:18:23.621512 IP (tos 0x0, ttl 255, id 102, offset 0, flags [none], proto VRRP (112), length 40) \ 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746" 10:18:25.621977 IP (tos 0x0, ttl 255, id 103, offset 0, flags [none], proto VRRP (112), length 40) \ 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746" ......... The output contains several pieces of data that be useful for debugging problems: authtype - the type of authentication in use (authentication configuration directive) vrid - the virtual router id (virtual_router_id configuration directive) prio - the priority of the device (priority configuration directive) intvl - how often to send out advertisements (advert_int configuration directive) auth - the authentication token sent (auth_pass configuration directive) Conclusion
In this article I described how to set up a host to use the keepalived daemon, and provided a sample configuration file that can be used to failover virtual interfaces between servers. Keepalived has a slew of options not covered here, and I will refer you to the keepalived source code and documentation for additional details
在Keepalived集群中，其實并沒有嚴格意義上的主、備節點，雖然可以在Keepalived配置文件中設置“state”選項為“MASTER”狀態，但是這并不意味著此節點一直就是Master角色。控制節點角色的是Keepalived配置文件中的“priority”值，但并它并不控制所有節點的角色，另一個能改變節點角色的是在vrrp_script模塊中設置的“weight”值，這兩個選項對應的都是一個整數值，其中“weight”值可以是個負整數，一個節點在集群中的角色就是通過這兩個值的大小決定的。 在一個一主多備的Keepalived集群中，“priority”值最大的將成為集群中的Master節點，而其他都是Backup節點。在Master節點發生故障后，Backup節點之間將進行“民主選舉”，通過對節點優先級值“priority”和““weight”的計算，選出新的Master節點接管集群服務。
在vrrp_script模塊中，如果不設置“weight”選項值，那么集群優先級的選擇將由Keepalived配置文件中的“priority”值決定，而在需要對集群中優先級進行靈活控制時，可以通過在vrrp_script模塊中設置“weight”值來實現。下面列舉一個實例來具體說明。
假定有A和B兩節點組成的Keepalived集群，在A節點keepalived.conf文件中，設置“priority”值為100，而在B節點keepalived.conf文件中，設置“priority”值為80，并且A、B兩個節點都使用了“vrrp_script”模塊來監控mysql服務，同時都設置“weight”值為10，那么將會發生如下情況。
在兩節點都啟動Keepalived服務后，正常情況是A節點將成為集群中的Master節點，而B自動成為Backup節點，此時將A節點的mysql服務關閉，通過查看日志發現，并沒有出現B節點接管A節點的日志，B節點仍然處于Backup狀態，而A節點依舊是Master狀態，在這種情況下整個HA集群將失去意義。
下面就分析一下產生這種情況的原因，這也就是Keepalived集群中主、備角色選舉策略的問題。下面總結了在Keepalived中使用vrrp_script模塊時整個集群角色的選舉算法，由于“weight”值可以是正數也可以是負數，因此，要分兩種情況進行說明。
1. “weight”值為正數時 在vrrp_script中指定的腳本如果檢測成功，那么Master節點的權值將是“weight值與”priority“值之和，如果腳本檢測失敗，那么Master節點的權值保持為“priority”值，因此切換策略為： Master節點“vrrp_script”腳本檢測失敗時，如果Master節點“priority”值小于Backup節點“weight值與”priority“值之和，將發生主、備切換。 Master節點“vrrp_script”腳本檢測成功時，如果Master節點“weight”值與“priority”值之和大于Backup節點“weight”值與“priority”值之和，主節點依然為主節點，不發生切換。
2. “weight”值為負數時 在“vrrp_script”中指定的腳本如果檢測成功，那么Master節點的權值仍為“priority”值，當腳本檢測失敗時，Master節點的權值將是“priority“值與“weight”值之差，因此切換策略為： Master節點“vrrp_script”腳本檢測失敗時，如果Master節點“priority”值與“weight”值之差小于Backup節點“priority”值，將發生主、備切換。 Master節點“vrrp_script”腳本檢測成功時，如果Master節點“priority”值大于Backup節點“priority”值時，主節點依然為主節點，不發生切換。
在熟悉了Keepalived主、備角色的選舉策略后，再來分析一下剛才實例，由于A、B兩個節點設置的“weight”值都為10，因此符合選舉策略的第一種，在A節點停止Mysql服務后，A節點的腳本檢測將失敗，此時A節點的權值將保持為A節點上設置的“priority”值，即為100，而B節點的權值將變為“weight”值與“priority”值之和，也就是90（10+80），這樣就出現了A節點權值仍然大于B節點權值的情況，因此不會發生主、備切換。
對于“weight”值的設置，有一個簡單的標準，即“weight”值的絕對值要大于Master和Backup節點“priority”值之差。對于上面A、B兩個節點的例子，只要設置“weight”值大于20即可保證集群正常運行和切換。由此可見，對于“weight值的設置，要非常謹慎，如果設置不好，將導致集群角色選舉失敗，使集群陷于癱瘓狀態。
如果你在讀這篇文章，說明你跟大多數開發者一樣對GIT感興趣，如果你還沒有機會來試一試GIT，我想現在你就要了解它了。 GIT不僅僅是個版本控制系統，它也是個內容管理系統(CMS),工作管理系統等。如果你是一個具有使用SVN背景的人，你需要做一定的思想轉換，來適應GIT提供的一些概念和特征。所以，這篇文章的主要目的就是通過介紹GIT能做什么、它和SVN在深層次上究竟有什么不同來幫助你認識它。 那好，這就開始吧… 1.GIT是分布式的，SVN不是： 這是GIT和其它非分布式的版本控制系統，例如SVN，CVS等，最核心的區別。如果你能理解這個概念，那么你就已經上手一半了。需要做一點聲明，GIT并不是目前第一個或唯一的分布式版本控制系統。還有一些系統，例如Bitkeeper, Mercurial等，也是運行在分布式模式上的。但GIT在這方面做的更好，而且有更多強大的功能特征。 GIT跟SVN一樣有自己的集中式版本庫或服務器。但，GIT更傾向于被使用于分布式模式，也就是每個開發人員從中心版本庫/服務器上chect out代碼后會在自己的機器上克隆一個自己的版本庫?？梢赃@樣說，如果你被困在一個不能連接網絡的地方時，就像在飛機上，地下室，電梯里等，你仍然能夠提 交文件，查看歷史版本記錄，創建項目分支，等。對一些人來說，這好像沒多大用處，但當你突然遇到沒有網絡的環境時，這個將解決你的大麻煩。 同樣，這種分布式的操作模式對于開源軟件社區的開發來說也是個巨大的恩賜，你不必再像以前那樣做出補丁包，通過email方式發送出去，你只需要創建一個分支，向項目團隊發送一個推請求。這能讓你的代碼保持最新，而且不會在傳輸過程中丟失。GitHub.com就是一個這樣的優秀案例。 有些謠言傳出來說subversion將來的版本也會基于分布式模式。但至少目前還看不出來。 2.GIT把內容按元數據方式存儲，而SVN是按文件： 所有的資源控制系統都是把文件的元信息隱藏在一個類似.svn,.cvs等的文件夾里。如果你把.git目錄的 體積大小跟.svn比較，你會發現它們差距很大。因為,.git目錄是處于你的機器上的一個克隆版的版本庫，它擁有中心版本庫上所有的東西，例如標簽，分 支，版本記錄等。 3.GIT分支和SVN的分支不同： 分支在SVN中一點不特別，就是版本庫中的另外的一個目錄。如果你想知道是否合并了一個分支，你需要手工運行像這樣的命令svn propget svn:mergeinfo，來確認代碼是否被合并。感謝Ben同學指出這個特征。所以，經常會發生有些分支被遺漏的情況。 然而，處理GIT的分支卻是相當的簡單和有趣。你可以從同一個工作目錄下快速的在幾個分支間切換。你很容易發現未被合并的分支，你能簡單而快捷的合并這些文件。
4.GIT沒有一個全局的版本號，而SVN有： 目前為止這是跟SVN相比GIT缺少的最大的一個特征。你也知道，SVN的版本號實際是任何一個相應時間的源代 碼快照。我認為它是從CVS進化到SVN的最大的一個突破。因為GIT和SVN從概念上就不同，我不知道GIT里是什么特征與之對應。如果你有任何的線 索，請在評論里奉獻出來與大家共享。 更新：有些讀者指出，我們可以使用GIT的SHA-1來唯一的標識一個代碼快照。這個并不能完全的代替SVN里容易閱讀的數字版本號。但，用途應該是相同的。 5.GIT的內容完整性要優于SVN： GIT的內容存儲使用的是SHA-1哈希算法。這能確保代碼內容的完整性，確保在遇到磁盤故障和網絡問題時降低對版本庫的破壞。這里有一個很好的關于GIT內容完整性的討論 –http://stackoverflow.com/questions/964331/git-file-integrity GIT和SVN之間只有這五處不同嗎？當然不是。我想這5個只是“最基本的”和“最吸引人”的，我只想到這5點。如果你發現有比這5點更有趣的，請共享出來，歡迎。
mysql中 myisam 引擎不支持事務的概念，多用于數據倉庫這樣查詢多而事務少的情況，速度較快。
mysql中 innoDB 引擎支持事務的概念，多用于web網站后臺等實時的中小型事務處理后臺。
而oracle沒有引擎的概念，oracle有OLTP和OLAP模式的區分，兩者的差別不大，只有參數設置上的不同。
oracle無論哪種模式都是支持事務概念的，oracle是一個不允許讀臟的數據庫系統。
當今的數據處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果.
OLTP:
也稱為面向交易的處理系統，其基本特征是顧客的原始數據可以立即傳送到計算中心進行處理，并在很短的時間內給出處理結果。
這樣做的最大優點是可以即時地處理輸入的數據，及時地回答。也稱為實時系統(Real time System)。衡量聯機事務處理系統的一個重要性能指標是系統性能，具體體現為實時響應時間(Response Time)，即用戶在終端上送入數據之后，到計算機對這個請求給出答復所需要的時間。OLTP是由數據庫引擎負責完成的。
OLTP 數據庫旨在使事務應用程序僅寫入所需的數據，以便盡快處理單個事務。
OLAP:
簡寫為OLAP,隨著數據庫技術的發展和應用，數據庫存儲的數據量從20世紀80年代的兆（M）字節及千兆（G）字節過渡到現在的兆兆（T）字節和千兆兆（P）字節，同時，用戶的查詢需求也越來越復雜，涉及的已不僅是查詢或操縱一張關系表中的一條或幾條記錄，而且要對多張表中千萬條記錄的數據進行數據分析和信息綜合，關系數據庫系統已不能全部滿足這一要求。在國外，不少軟件廠商采取了發展其前端產品來彌補關系數據庫管理系統支持的不足，力圖統一分散的公共應用邏輯，在短時間內響應非數據處理專業人員的復雜查詢要求。
聯機分析處理（OLAP）系統是數據倉庫系統最主要的應用，專門設計用于支持復雜的分析操作，側重對決策人員和高層管理人員的決策支持，可以根據分析人員的要求快速、靈活地進行大數據量的復雜查詢處理，并且以一種直觀而易懂的形式將查詢結果提供給決策人員，以便他們準確掌握企業（公司）的經營狀況，了解對象的需求，制定正確的方案。
第一種：直接啟動 安裝： tar zxvf redis-2.8.9.tar.gz cd redis-2.8.9 #直接make 編譯 make #可使用root用戶執行`make install`，將可執行文件拷貝到/usr/local/bin目錄下。這樣就可以直接敲名字運行程序了。 make install 啟動： #加上`&`號使redis以后臺程序方式運行 ./redis-server & 檢測： #檢測后臺進程是否存在 ps -ef |grep redis #檢測6379端口是否在監聽 netstat -lntp | grep 6379 #使用`redis-cli`客戶端檢測連接是否正常 ./redis-cli 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set key "hello world" OK 127.0.0.1:6379> get key "hello world" 停止： #使用客戶端 redis-cli shutdown #因為Redis可以妥善處理SIGTERM信號，所以直接kill -9也是可以的 kill -9 PID 第二種：通過指定配置文件啟動 配置文件 可為redis服務啟動指定配置文件，配置文件 redis.conf 在Redis根目錄下。 #修改daemonize為yes，即默認以后臺程序方式運行（還記得前面手動使用&號強制后臺運行嗎）。 daemonize no #可修改默認監聽端口 port 6379 #修改生成默認日志文件位置 logfile "/home/futeng/logs/redis.log" #配置持久化文件存放位置 dir /home/futeng/data/redisData
啟動時指定配置文件 redis-server ./redis.conf #如果更改了端口，使用`redis-cli`客戶端連接時，也需要指定端口，例如： redis-cli -p 6380
其他啟停同 直接啟動 方式。配置文件是非常重要的配置工具，隨著使用的逐漸深入將顯得尤為重要，推薦在一開始就使用配置文件。 第三種： 使用Redis啟動腳本設置開機自啟動 啟動腳本 推薦在生產環境中使用啟動腳本方式啟動redis服務。啟動腳本 redis_init_script 位于位于Redis的 /utils/ 目錄下。 #大致瀏覽下該啟動腳本，發現redis習慣性用監聽的端口名作為配置文件等命名，我們后面也遵循這個約定。 #redis服務器監聽的端口 REDISPORT=6379 #服務端所處位置，在make install后默認存放與`/usr/local/bin/redis-server`，如果未make install則需要修改該路徑，下同。 EXEC=/usr/local/bin/redis-server #客戶端位置 CLIEXEC=/usr/local/bin/redis-cli #Redis的PID文件位置 PIDFILE=/var/run/redis_${REDISPORT}.pid #配置文件位置，需要修改 CONF="/etc/redis/${REDISPORT}.conf" 配置環境 1. 根據啟動腳本要求，將修改好的配置文件以端口為名復制一份到指定目錄。需使用root用戶。 mkdir /etc/redis cp redis.conf /etc/redis/6379.conf 2. 將啟動腳本復制到/etc/init.d目錄下，本例將啟動腳本命名為redisd（通常都以d結尾表示是后臺自啟動服務）。 cp redis_init_script /etc/init.d/redisd 3. 設置為開機自啟動 此處直接配置開啟自啟動 chkconfig redisd on 將報錯誤： service redisd does not support chkconfig 參照 此篇文章 ，在啟動腳本開頭添加如下兩行注釋以修改其運行級別： #!/bin/sh # chkconfig: 2345 90 10 # description: Redis is a persistent key-value database # 再設置即可成功。 #設置為開機自啟動服務器 chkconfig redisd on #打開服務 service redisd start #關閉服務 service redisd stop http://www.tuicool.com/articles/aQbQ3u
mysql mysqldump 只導出表結構 不導出數據 mysqldump --opt -d 數據庫名 -u root -p > xxx.sql 備份數據庫
#mysqldump 數據庫名 >數據庫備份名 #mysqldump -A -u用戶名 -p密碼 數據庫名>數據庫備份名 #mysqldump -d -A --add-drop-table -uroot -p >xxx.sql 1.導出結構不導出數據
mysqldump --opt -d 數據庫名 -u root -p > xxx.sql 2.導出數據不導出結構 mysqldump -t 數據庫名 -uroot -p > xxx.sql 3.導出數據和表結構 mysqldump 數據庫名 -uroot -p > xxx.sql 4.導出特定表的結構
mysqldump -uroot -p -B 數據庫名 --table 表名 > xxx.sql 導入數據：
由于mysqldump導出的是完整的SQL語句，所以用mysql客戶程序很容易就能把數據導入了： #mysql 數據庫名 < 文件名 #source /tmp/xxx.sql
Haproxy根目錄：F:\SysWork\openSource\haproxy\haproxy1.5.12 配置文件haproxy.cfg如下： global log 127.0.0.1 local0 # maxconn 4096 chroot F:\SysWork\openSource\haproxy\haproxy1.5.12 # uid 99 # gid 99 # daemon nbproc 1 pidfile F:\SysWork\openSource\haproxy\haproxy1.5.12\haproxy.pid debug quiet defaults log 127.0.0.1 local3 mode http option httplog option httpclose option dontlognull option forwardfor option redispatch retries 3 maxconn 8192 balance roundrobin timeout connect 50000 timeout client 50000 timeout server 50000 timeout check 20000 listen httpweb :8100 mode http balance roundrobin option httpclose option forwardfor option httpchk GET /index.html #心跳檢測的文件 server httpweb1 localhost:9200 cookie 1 weight 5 check inter 2000 rise 2 fall 3 server httpweb2 localhost:9300 cookie 2 weight 3 check inter 2000 rise 2 fall 3 listen httpservice :8200 mode http balance roundrobin option httpclose option forwardfor option httpchk GET /index.html #心跳檢測的文件 server httpservice1 localhost:9200 cookie 3 weight 5 check inter 2000 rise 2 fall 3 server httpservice2 localhost:9300 cookie 4 weight 3 check inter 2000 rise 2 fall 3 listen tcpservice bind 0.0.0.0:8400 mode tcp server tcpservice1 localhost:20880 cookie 5 weight 3 check inter 2000 rise 2 fall 3 listen status 127.0.0.1:8300 stats enable stats uri /status stats auth admin:123456 stats realm (Haproxy\ statistic) 啟動命令： F:\SysWork\openSource\haproxy\haproxy1.5.12>haproxy.exe -f haproxy.cfg [WARNING] 240/200829 (11260) : parsing [haproxy.cfg:14] : 'option httplog' not usable with proxy 'tcpservice' (needs 'mo de http'). Falling back to 'option tcplog'. [WARNING] 240/200829 (11260) : config : 'option forwardfor' ignored for proxy 'tcpservice' as it requires HTTP mode. [WARNING] 240/200829 (11260) : config : proxy 'tcpservice' : ignoring cookie for server 'tcpservice1' as HTTP mode is di sabled. Available polling systems : poll : pref=200, test result OK select : pref=150, test result FAILED Total: 2 (1 usable), will use poll. Using poll() as the polling mechanism. [WARNING] 240/200829 (11260) : [haproxy.main()] Cannot raise FD limit to 4019. [WARNING] 240/200829 (11260) : [haproxy.main()] FD limit (256) too low for maxconn=2000/maxsock=4019. Please raise 'ulim it-n' to 4019 or more to avoid any trouble. [WARNING] 240/200830 (11260) : Server httpweb/httpweb1 is DOWN, reason: Layer4 connection problem, info: "Connection ref used", check duration: 1000ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] 240/200831 (11260) : Server httpweb/httpweb2 is DOWN, reason: Layer4 connection problem, info: "Connection ref used", check duration: 1000ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] 240/200831 (11260) : proxy 'httpweb' has no server available! [WARNING] 240/200831 (11260) : Server httpservice/httpservice1 is DOWN, reason: Layer4 connection problem, info: "Connec tion refused", check duration: 1000ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] 240/200831 (11260) : Server httpservice/httpservice2 is DOWN, reason: Layer4 connection problem, info: "Connec tion refused", check duration: 998ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] 240/200831 (11260) : proxy 'httpservice' has no server available! 監控頁面地址：http://127.0.0.1:8300/status 現在配置文件除了http代理之外，還有tcp代理，http代理就是簡單的代理tomcat的請求。把haproxy的請求分發給多個tomcat，而tcp代理我這里是代理的dubbo請求，dubbo啟動起來的時候20880端口，但是我們可以通過這里的8400端口提供請求 我們之前都是通過telnet localhost 20880可以看到dubbo控制臺，現在可以通過telnet localhost 8400查看dubbo控制臺
nginx的根目錄是：D:\Sys\server\nginx\nginx-1.9.4\ nginx配置文件目錄：D:\Sys\server\nginx\nginx-1.9.4\conf nginx.conf 配置文件如下： #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; include vhosts/*.conf; }
這個主目錄只保留基本配置 include vhosts/*.conf;這句話就是引用虛擬主機目錄的配置文件 在該目錄下面創建vhosts目錄： D:\Sys\server\nginx\nginx-1.9.4\conf\vhosts 虛擬主機(實際里面就是配置upstream和server，然后server里面配置監聽端口和serverName，還有location)目錄里面的配置文件分別為： www.abin.com.conf www.lee.com.conf www.abin.com.conf的配置為： upstream abin { server localhost:9200 weight=10; } # another virtual host using mix of IP-, name-, and port-based configuration server { listen 8000; server_name www.abin.com abin.com; location / { #反向代理的地址 proxy_pass http://abin; root html; index index.html index.htm; } location /abin { #反向代理的地址 proxy_pass http://abin; root html; index index.html index.htm; } } www.lee.com.conf的配置為： upstream lee { server localhost:9300 weight=10;//這個配置為tomcat的請求地址 } # another virtual host using mix of IP-, name-, and port-based configuration server { listen 8000; server_name www.lee.com lee.com; location / { #反向代理的地址 proxy_pass http://lee; root html; index index.html index.htm; } location /abin { #反向代理的地址 proxy_pass http://lee; root html; index index.html index.htm; } } 測試： http://www.lee.com:8000/ http://www.lee.com:8000/abin
http://lee.com:8000/abin http://www.lee.com:8000/ http://www.lee.com:8000/lee
http://lee.com:8000/lee
我的tomcat服務器的web.xml都配置了<webcome-list>index.html</welcome-list>,
tomcat:9200配置了abin這個java工程，它里面的index.html內容為hello，abin
tomcat:9300配置了abin這個java工程，它里面的index.html內容為hello，lee 那么上面的第二個地址打印hello，abin 那么上面的第四個地址打印hello，lee 本地hosts文件配置為： 127.0.0.1 localhost 127.0.0.1 www.abin.com abin.com 127.0.0.1 www.lee.com lee.com
支付寶這次面試,直接是一波流搞定,沒有HR問為毛辭職,職業規劃之類的問題,都是直接上干貨的,技術. 筆試40分鐘,然后帶上試卷直接去面試,面試時間長短就不清楚了,我大概面了1個小時左右. 筆試: 1. cookie 和 session 的區別 2. JVM 內存模型 3. SQL注入的原理 4. 悲觀鎖 和 樂觀鎖 5. 讀程序,輸出結果. 關于treemap的 6. linux 基礎命令,統計日志中的信息 7. java 分布式集群 8. 一道設計題,具體到數據庫的表.大概是淘寶的搜索中,輸入手機,會出來很多類型,按品牌按價格區間按手機種類. 還有2道題我記不住了. 面試: 1.介紹你做過的項目,用到的技術,涉及到的模塊,然后從項目中問各種技術實現的細節(為了確保你是真的懂了). 2.看你的試卷,喊你講解做題的思路,以及這樣結果的原因.(考的是各位的java基礎知識了,這點是繞不過去的,懂了就懂了啊,只有平時多看書) 3.團購6位驗證碼以及團購成功后,發送到你手機上的條碼的實現方式.(第一個問題我說用隨機數+時間來驗證.第二個問題老實說,我也沒答上來,我說用序列,面試官說序列到后期20位以上的時候,用戶體驗很差的) 4.淘寶上是如何保證庫存和訂單之間的數據準確性的.(CICS Tuxedo，考點是分布式事務,這個問題我也沒答上來,最后他問我有什么問題問他的時候,我就反問的這個問題,面試官人挺好的,給我耐心的講解了一遍淘寶的實現方式以及 epay的實現方式. 淘寶是通過分布式事物,中間用了一個叫協調者角色的程序,當那邊點擊購買時,會庫存減一,保存一條預扣的狀態,但是是個預準備狀態,然后做成功后,協調者會在另一個數據庫生成訂單,然后這個訂單也是預狀態,等兩邊都準備好以后,通知協調者,又協調者統一完成這2個數據庫的事物,從而達到完成一筆交易的目的,若其中一方失敗,則將預扣的數字返回到庫存從而實現類似回滾的操作.) 5.索引的原理.能否構建時間索引.時間索引構建后會存在什么問題.(索引原理我是回答的堆表索引的構建原理以及查詢原理,但是關于時間索引的問題,我也沒回答出個所以然來,看面試官的反饋,好像回答得不夠好吧) 6.你們數據庫的數據量有多大,(回答:我們是電信方面的系統,表上億的數據很正常).問:如果保證效率? (我是如此回答的,各位自行結合自身的情況參考.答:后臺J OB程序會定期備份,把生產表數據移走,然后備份表也會再備份一次,如此剃度的備份,保證生產庫的數據是最小的.然后備份表采用分區和子分區,加上構建戰略索引(分析系統的sql,常用 查詢字段構建復合索引,以減少每次查詢時對表的訪問次數)). 7.SQL注入的原理以及如何預防,并舉例.(這個相對簡單,網上一搜一大片) 8.使用過Memcache么? 用在項目中哪些地方? (答,在門戶主機上使用,緩存session,分布式的時候,統一訪問這臺主機驗證用戶session是否存在,來維持回話的狀態和實現回話同步.又追問:java代碼中如何實現訪問門戶服務器的這個session池子的? 幾年前的代碼,確實忘記了..于是坦白的說,記不清楚了 ) 這些是主要的問題,當你回答一個大問題時中間還有很多比較碎的追問性質的小問題,總體給我的感覺是,氛圍很輕松+愉快的,技術層面上還是需要你真正的理解透徹一些關鍵技術點,才能做到應付各種追問和給出滿意的答案吧.如果只是一知半解想去蒙混過關肯定是不行的,畢竟在支付寶的技術大牛面前,多追問幾句,也就把你逼到死角了. 還有一點比較重要的感覺就是,他們比較在意你是否了解當下的一些比較熱的技術點,比如淘寶的秒殺,是如何保證高并發下的安全性和性能,新浪微博那種大數據量的發送,怎么就保證正確性和時效性的. 自我感覺面試得很一般,估計希望比較小吧,共享這些希望能給各位小伙伴帶來實際上的幫助.
環境 配置Mysql的MasterSlave至少需要兩臺機器。我這里使用三臺虛擬機進行測試。三臺機器配置完全一樣，MySQL安裝的路徑也是一樣： 第一臺：10.1.5.181； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1 第二臺：10.1.5.182； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1 第三臺：10.1.5.183； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1 第一臺10.1.5.181用作master，其他兩臺用做slave。 配置Master 在10.1.5.181這臺服務器上找到MySQL的配置文件my.ini。我的具體路徑是在C:\ProgramData\MySQL\MySQL Server 5.6下。 打開配置文件，在最下面添加如下配置： ************************************************************************************ #Master start
#日志輸出地址 主要同步使用
log-bin=master-bin.log
#同步數據庫
binlog-do-db=test
#主機id 不能和從機id重復
server-id=1
#Master end ************************************************************************************ master的配置比較少，server-id是為這一組master/slave服務器定的唯一id，master/slave服務器中不能重復。在binlog-do-db中填寫對象要同步的數據庫，如果有多個，用逗號分隔，或再寫一行如binlog-do-db=test2。 配置Slave 同樣在第二臺機器上10.1.5.181找到配置文件my.ini。打開配置文件，在最下面添加如下配置： ***************************************************************************** report-host = 10.1.5.181
report-user = root
report-password = root123
log-bin = slave-bin.log
replicate-do-db = test server-id = 2 ***************************************************************************** 這里需要添加master的IP，連接master的用戶名和密碼，生產環境中需要新建一個用戶專門來處理replication，這里沒有新建用戶，用root做測試。端口沒有配置，就是使用默認的3306，如果端口有變化，則通過report-port=？來配置。log-bin是記錄日志的位置。 然后通過命令start slave來啟動mysql的復制功能。如果在start slave過程中出現異常： The server is not configured as slave; fix in config file or with CHANGE MASTER TO 可以通過下面語句解決： change master to master_host='10.1.5.181',master_user='root',master_password='root123',master_log_file='master-bin.000001' ,master_log_pos=120; 使用show slave status 命令來查來看運行狀態。特別關注兩個屬性，是否為“Yes”，如果都為“Yes”，則說明運行正常。 Slave_IO_Running：連接到主庫，并讀取主庫的日志到本地，生成本地日志文件 Slave_SQL_Running:讀取本地日志文件，并執行日志里的SQL命令。 同樣的配置再在第三臺機器上配置一下，server-id修改成3。重啟slave和master的mysqld服務。然后測試，在三臺服務器上都確保有數據庫test，然后在master服務器的test數據庫上建表和數據，之后再兩臺slave上面都會看見數據的同步。 Mysql的MasterSlave同步時通過二進制文件進行同步的。在Master端，你可以在C:\ProgramData\MySQL\MySQL Server 5.6\data的master-bin.log日志文件里看見所有同步的sql腳本，master-bin.log是配置master時候輸入的。在slave端，你可以在MySQL02-relay-bin類似的文件中找到日志。
http://www.cnblogs.com/haoxinyue/archive/2013/04/02/2995280.html
|