秒殺購物商城業(yè)務服務-分布式架構介紹

基于MySQL數據庫集群技術實現服務的高可用基于Tomcat的集群負載機制實現Tomcat服務器的高可用基于Nginx負載均衡機制實現負載均衡（介紹和配置）基于Redis緩存服務實現數據緩存控制相關介紹和技術點分析對未來的分布式技術架構擴展和延伸介紹（包含云原生部分）

基于MySQL數據庫集群技術實現服務的高可用

高可用架構對于互聯網服務基本是標配，無論是應用服務還是數據庫服務都需要做到高可用。對于一個系統而言，可能包含很多模塊，比如前端應用，緩存，數據庫，搜索，消息隊列等，每個模塊都需要做到高可用，才能保證整個系統的高可用。對于數據庫服務而言，高可用可能更復雜，對用戶的服務可用，不僅僅是能訪問，還需要有正確性保證，因此數據庫的高可用需要更加認證對待。

MySQL高可用架構分類

MySQL實現高可用之MMMMySQL實現高可用之MHAMySQL實現高可用之主從架構MySQL實現高可用之Cluster模式

MMM的技術分析

MMM（Master-Master replication manager for MySQL）是一套支持雙主故障切換和雙主日常管理的腳本程序。

MMM的基礎組件分析

mmm_mond：監(jiān)控進程，負責所有的監(jiān)控工作，決定和處理所有節(jié)點角色活動。因此，腳本需要在監(jiān)管上運行。mmm_agentd：運行在每個msql服務器上的代理進程，完成監(jiān)控的探針工作和執(zhí)行簡單的遠端服務設置。此腳本需要在被監(jiān)管機上運行。mmm_control：一個簡單的腳本，提供管理mmm_mond進行的命令。

MMM實現基本實現原理

MMM提供了自動和手動兩種方式移除一組服務器中復制延遲較高的服務器的虛擬ip，同時它還可以備份數據，實現兩節(jié)點之間的數據同步等。

(相關資料圖)

MySQL本身沒有提供replication failover的解決方案，通過MMM方案能實現服務器的故障轉移，從而實現mysql的高可用。

MHA簡介

MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司的youshimaton（現就職于Facebook公司）開發(fā)，是一套優(yōu)秀的作為MySQL高可用性環(huán)境下故障切換和主從提升的高可用軟件。

MHA的基礎組件

MHA由兩部分組成：MHA Manager（管理節(jié)點）和MHA Node（數據節(jié)點）。

MHA Manager可以單獨部署在獨立的機器上管理多個master-slave集群，也可以部署在一臺slave節(jié)點上。

MHA的實現原理

MHA Node運行在每臺MySQL服務器上，MHA Manager會定時探測集群中的master節(jié)點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然后將所有其他的slave重新指向新的master。整個故障轉移過程對應用程序完全透明。

MySQL主從架構

此種架構，一般初創(chuàng)企業(yè)比較常用，也便于后面步步的擴展

此架構特點

成本低，布署快速、方便讀寫分離還能通過及時增加從庫來減少讀庫壓力主庫單點故障數據一致性問題（同步延遲造成）

MySQL Cluster基本概念

MySQL Cluster簡單地講是一種MySQL集群的技術，是由一組計算機構成，每臺計算機可以存放一個或者多個節(jié)點，其中包括MySQL服務器，DNB Cluster的數據節(jié)點，管理其他節(jié)點，以及專門的數據訪問程序，這些節(jié)點組合在一起，就可以為應用提高可高性能、高可用性和可縮放性的Cluster數據管理；

基于Tomcat的集群負載機制實現Tomcat服務器的高可用

Tomcat集群原理

通過Nginx負載均衡進行請求轉發(fā)

Tomcat集群能帶來什么

提高服務的性能, 并發(fā)能力, 以及高可用性提供項目架構的橫向擴展能力

Tomcat集群產生什么問題

Session登錄信息存儲以及讀取的問題服務器定時任務并發(fā)的問題

Tomcat 單服務體系架構

在這個架構圖中，一層Nginx，首先Nginx主要職責給Tomcat一層反向代理。

此外，Nginx還可以FTPServer指定的目錄再做一層目錄轉發(fā)，保證上傳上去的圖片實時可以通過http協議訪問到。單服務架構先不用考慮集群碰到的各種問題

Tomcat集群"簡單版"

比如，我們的登錄的時候登錄了A服務器，session信息存儲到A服務器上了，假設我們使用的負載均衡策略是ip hash，那么登錄信息還可以從A服務器上訪問，但是這個有可能造成某些服務器壓力過大，某些服務器又沒有什么壓力，這個時候壓力過大的機器(包括網卡帶寬)有可能成為瓶頸，并且請求不夠分散。

首先要解決Session共享的問題

這時候我們使用輪詢或者最小連接負載均衡策略，就導致了，第一次訪問A服務器，第二次可能訪問到B服務器，這個時候存儲在A服務器上的session信息在B服務器上讀取不到。

典型負載均衡策略分析

打個比方，我們有輪詢，權重，地址散列，地址散列又分為原ip地址散列hash，目標ip地址散列hash，最少連接，加權最少連接，還有繼續(xù)升級的很多種策略

輪詢：優(yōu)點：實現簡單，缺點：不考慮每臺服務器處理能力權重：優(yōu)點：考慮了服務器處理能力的不同地址散列：優(yōu)點：能實現同一個用戶訪問同一個服務器最少連接：優(yōu)點：使集群中各個服務器負載更加均勻加權最少連接：在最少連接的基礎上，為每臺服務器加上權值。算法為(活動連接數*256+非活動連接數)/權重，計算出來的值小的服務器優(yōu)先被選擇。

Session管理-Session Sticky粘滯會話：

對于同一個連接中的數據包，負載均衡會將其轉發(fā)至后端固定的服務器進行處理。

解決了我們session共享的問題，但是它有什么缺點呢？

一臺服務器運行的服務掛掉，或者重啟，上面的 session 都沒了負載均衡器成了有狀態(tài)的機器，為以后實現容災造成了羈絆

Session管理-Session 復制

就是每一個Tomcat都存儲我們的Session，不同的tomcat之間進行拷貝復制。

解決了我們session共享的問題，但是它有什么缺點呢？

應用服務器間帶寬問題，因為需要不斷同步session數據大量用戶在線時，服務器占用內存過多

Session管理-基于Cookie

主要用于我們將session會話如同token一般存儲在我們的前端

解決了我們session共享的問題，但是它有什么缺點呢？

cookie 的長度限制cookie存于瀏覽器，安全性是一個問題

Session管理-Session 服務器

就是通過一個專門管理session會話的管理器服務，進行集中化存儲和管理session

解決了我們session共享的問題，這種方案需要思考哪些問題呢？保證 session 服務器的可用性，session服務器單點如何解決？

我們在寫應用時需要做調整存儲session的業(yè)務邏輯打個比方，我們?yōu)榱颂岣遱ession server的可用性，可以繼續(xù)給session server做集群

Tomcat單機部署多應用

解壓2個tomcat, 分別命名為tomcatA和tomcatB分別設置2個tomcat的URIEncoding, 將tomcat的conf/server.xml里的port修改為兩個不同端口。

設置tomcat的環(huán)境變量

tomcatA的環(huán)境變量和以往一樣, 不做改變

設置tomcat的環(huán)境變量

??sudo vim /ect/profile??

在profile文件里新增

export CATALINA_BASE=/Users/tomcat/apache-tomcat-9.0.21export CATALINA_HOME=/Users/tomcat/apache-tomcat-9.0.21export TOMCAT_HOME=/Users/tomcat/apache-tomcat-9.0.21

export CATALINA_2_BASE=/Users/tomcat/tomcat2export CATALINA_2_HOME=/Users/tomcat/tomcat2export TOMCAT_2_HOME=/Users/tomcat/tomcat2

強制保存退出

繼續(xù)配置tomcatB下的catalina.sh里的內容,

cd tomcat目錄，在# OS specific support. $var mustbe set to either true or false.下加入。

sudo vi catalina.shexport CATALINA_BASE=$CATALINA_2_BASEexport CATALINA_HOME=$CATALINA_2_HOME

執(zhí)行刷新環(huán)境變量

??source /etc/profile??

使環(huán)境變量生效, 執(zhí)行

??echo $CATALINA_2_BASE??

如果有輸出, 即環(huán)境變量已經生效

??/Users/tomcat/tomcat2??

分別進入兩個tomcat下的bin目錄啟動tomcat, 正常即可

配置nginx

修改host

??sudo vim /etc/hosts??

所謂tomcat集群，就是可以向外提供并行服務的多臺機器，任何一臺服務器宕機，其它服務器可以替代它向外提供服務，而不影響用戶訪問。

nginx是一個常用的反向代理服務，可自定義模塊，實現請求轉發(fā)及負載均衡（根具體采用策略有關）。為了tomcat集群的高可用性，還需要實現nginx的雙機熱備。

一，如果僅是對外提供一個頁面訪問，不用區(qū)分單一用戶（不區(qū)分每個訪問session，不涉及用戶權限，用戶資料等內容），僅僅配置nginx負載均衡策略即可。

nginx負載均衡策略主要分一下四種：

1)、輪詢（默認）每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器宕機，能自動剔除。

2)、ip_hash 每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器。

3)、fair 按后端服務器的響應時間來分配請求，響應時間短的優(yōu)先分配。

4)、url_hash 按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。

二，如果涉及到用戶session，做一些鑒權緩存、存放臨時信息時，就必須做tomcat的session共享。

目前可參考到的session共享方式主要分為兩種。

1）利用tomcat自帶的組播機制，實現session復制。

對tomcat及應用的若干配置文件進行配置即可實現，網上有很多資料可參考。但這種方式些弊端，看過一些資料，不建議用session復制的方式。在實際使用過程中，也發(fā)現有存在session莫名失蹤的現象。

2）利用第三方機制存儲session。

比較常見的是tomcat集成memcached服務器來存儲session。實際項目中，我們采用過利用redis實現session存儲，redis高效的存取性能為高效的訪問提供了保障，但是目前redis的集群功能似乎沒有發(fā)布，如何解決redis的單點故障需要研究。

小結：是否實現session共享與nginx的負載策略有很大關系。比如采用輪詢策略，就必須實現session共享，因為客戶端會訪問到每臺服務器；而如果采用ip_hash策略，就可以不用考慮session共享的問題了，但是ip_hash有些缺陷使它不能隨便使用（如多臺pc使用同一個外網ip）。

最近發(fā)現一個nginx的粘連模塊（類似session粘連），可以看做nginx的第5種均衡策略。它利用客戶端cookie，對其寫入一個route參數，每次訪問可以根據route的值，固定的訪問一臺服務器，解決的session共享的問題。

Nginx是什么？

Nginx（發(fā)音同 engine x）是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，并在一個BSD-like 協議下發(fā)行。由俄羅斯的程序設計師Igor Sysoev(伊戈爾·西索夫)所開發(fā)，供俄國大型的入口網站及搜索引擎Rambler(漫步者)（俄文：Рамблер）使用。其特點是占有內存少，并發(fā)能力強，事實上nginx的并發(fā)能力確實在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：新浪、網易、 騰訊等。

優(yōu)點

可運行l(wèi)inux,并有 Windows移植版。在高連接并發(fā)的情況下，Nginx是Apache服務器不錯的替代品Nginx在美國是做虛擬主機生意的老板們經常選擇的軟件平臺之一。能夠支持高達50,000個并發(fā)連接數的響應

負載均衡的功能

轉發(fā)故障移除恢復添加高可用 Ha

我們想要使用Nginx那么就必須滿足上面的四個條件.我們配置負載均衡的目的是在于當用戶訪問我們的服務器的時候, 首先會通過 Nginx服務器來決定轉發(fā)到哪個Tomcat服務器上去給用戶提供服務, 當然這個概率是我們通過權重來配置的. 經過Nginx指派之后, 我們就可以處理高并發(fā)的訪問了, 這里就能達到負載均衡的目的.

Nginx如何實現負載均衡

Nginx的負載均衡是通過upstream來實現的，在upstream中指定若干個 server，格式如下：

myserver就是通過 upstream 定義的一組負載均衡模板，其中：

在配置完upstream后，還要讓客戶端過來的請求反向代理到myserver，格式如下：

完成了負載均衡的配置，但是在實際需求中除了上面的設置外，還會增加一些額外設置：

負載均衡策略設置請求上游服務器攜帶請求頭信息upstream模塊中其他參數設置

Nginx的負載均衡策略有5種方式：

除以上5種，還有一種：least-connected — 下一個請求被分配到擁有最少活動連接數的服務器。

編輯nginx配置文件(例中為/usr/local/ngnix/conf/nginx.conf)，找到http結點，

配置案例

http {    upstream myapp1 {        server 192.168.1.103:8080;        server 192.168.1.104:8080;   }   server {        listen 80;        server_name  localhost;        location /webautotest/ {            proxy_buffering off;            proxy_pass http://myapp1;        }    }}

重新加載配置文件

[root@localhost nginx-1.10.0]# /usr/local/ngnix/sbin/nginx -s reload

默認的負載均衡配置

http {    upstream myapp1 {        server srv1.example.com;        server srv2.example.com;        server srv3.example.com;    }    server {        listen 80;        location / {            proxy_pass http://myapp1;        }    }}

最少連接負載均衡

另一個負載均衡原則為least-connected。當一些請求花費較長時間來完成時，least-connected更“公平”的控制應用程序實例上的負載。配置了least-connected的負載均衡機制的情況下，nginx會盡量不讓負載繁忙的應用服務器上負載過多的請求，相反的，會把新的請求發(fā)送到比較不繁忙的服務器。

配置示例：

upstream myapp1 {        least_conn;        server srv1.example.com;        server srv2.example.com;        server srv3.example.com;}

會話持久性

注意，round-robin或least-connected負載均衡下，每個后續(xù)的客戶端可能被分發(fā)至不同服務器，不保證相同客戶端的請求總是被發(fā)送到相同的服務器。

如果有必要把客戶端綁定至特定服務器，則可使用ip-hash負載均衡機制。

ip-hash機制

ip-hash機制下，客戶端ip地址被用作hash key來判斷客戶端請求應該發(fā)送到哪個服務器，這種方法保證了來自相同客戶端的請求總是發(fā)送到相同服務器（如果服務器可用的話）

upstream myapp1 {    ip_hash;    server srv1.example.com;    server srv2.example.com;    server srv3.example.com;}

負載均衡權重

可通過配置服務器權重來影響負載均衡機制。上面的例子中，都未配置服務器權重，這意味著所有服務器都擁有相同的權重。針對round-robin負載機制，權重意味著更多或更少的請求傳送至服務器---假設有足夠的請求，且按統一方式處理請求，且足夠快完成請求處理。

配置示例：

upstream myapp1 {        server srv1.example.com weight=3;        server srv2.example.com;        server srv3.example.com;}

上例配置中，每發(fā)送至服務器實例的5個新的請求中，有3個發(fā)送到srv1,1個發(fā)送到srv2,另1個發(fā)送到srv3。

注：當前版本似乎只實現了round-robin機制下的權重設置

健康檢測

nginx反向代理實現包含服務器健康檢查。如果來自特定服務器的響應失敗，報錯，nginx將標記該服務器為failed，一段時間內盡量避免選擇此服務器作為隨后請求的分發(fā)服務器。max_fails機制設置fail_timeout期間，和服務器溝通失敗的連續(xù)重試次數，默認為1.當設置為0時，不做服務器健康檢測。fail_timeout定義了服務器被標記為failed的時長。fail_timeout時間間隔過后，nginx將開始使用活動客戶端請求來探測服務器，如果探測成功則標記服務器為活動服務器。

Nginx負載均衡配置項介紹

下面我們將介紹一下proxy模塊的參數：

各個參數介紹：

設置proxy_connect_timeout 為2秒，縮短超時時間，使其不至于太慢。