1.分布式：

分布式系統(tǒng)就是由多個節(jié)點(diǎn)（計算機(jī)服務(wù)器）組成的系統(tǒng)。而且這些節(jié)點(diǎn)一般不是孤立的，是互通的。這些聯(lián)通的節(jié)點(diǎn)上部署了我們的節(jié)點(diǎn)，并且相互的操作會有協(xié)同。

2.微服務(wù)：

通常而言，微服務(wù)是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用是由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨(dú)立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好的完成該任務(wù)。在所有情況下每個任務(wù)代表著一個小的業(yè)務(wù)能力。

傳統(tǒng)項(xiàng)目開發(fā)應(yīng)用程序都是單體型，所有的功能和業(yè)務(wù)模塊都集中在一個項(xiàng)目中，雖然開發(fā)部署比較方便，但是后期隨著業(yè)務(wù)的不斷增加，開發(fā)迭代和性能瓶頸等問題，將會困擾開發(fā)工作工作。微服務(wù)就是解決此問題的有效手段。要用微服務(wù)，涉及到的技術(shù)大致如下：

流行的微服務(wù)java項(xiàng)目框架：SpringBoot

微服務(wù)治理：Dubbo，SpringCloud

涉及技術(shù)：Zookeeper，Eureka，Redis，MQ等

3.分布式環(huán)境中如何實(shí)現(xiàn)單點(diǎn)登錄與session共享

在單服務(wù)器web應(yīng)用中，登錄用戶信息只需存在該服務(wù)的session中。在分布式系統(tǒng)中，微服務(wù)已成為主流，用戶登錄由某一個單點(diǎn)服務(wù)完成并存儲session后，在高并發(fā)量的請求到達(dá)服務(wù)端的時候通過負(fù)載均衡的方式分發(fā)到集群中的某個服務(wù)器，這樣就有可能導(dǎo)致同一個用戶的多次請求被分發(fā)到集群的不同服務(wù)器上，就會出現(xiàn)取不到session的情況；

目前實(shí)現(xiàn)session共享的解決方案：

（1）Session復(fù)制與共享 ?

多個server之間相互同步session,這樣每個server上都包含全部Service的session。

優(yōu)點(diǎn)：tomcat等多數(shù)主流web服務(wù)器都支持此功能。

不足：session同步需要數(shù)據(jù)傳輸，占內(nèi)網(wǎng)帶寬，有時延。所有服務(wù)器都包含所有session數(shù)據(jù)，特別是當(dāng)session中保存了較大的對象，而且對象變化較快時，性能下降顯著，這種特性使得web應(yīng)用的水平擴(kuò)展受到了限制。

（2）客戶端存儲法

服務(wù)端存儲所有用戶的session，內(nèi)存占用較大，也可以將session存儲到瀏覽器cookie中，每個端只要存儲一個用戶的數(shù)據(jù)了

優(yōu)點(diǎn)：服務(wù)端不需要存儲

缺點(diǎn)：每次http請求都攜帶session，占外網(wǎng)帶寬，數(shù)據(jù)存儲在端上，并在網(wǎng)絡(luò)傳輸，存在泄漏，篡改，竊取等安全隱患。Session存儲的數(shù)據(jù)大小受cookie限制。

（3）反向代理hash一致性

為了保證高可用，有多臺冗余，反向代理層能不能做一些事情，讓同一個用戶的請求保證落在一臺web服務(wù)上呢？

具體方案：反向代理層使用IP或http協(xié)議中的某些業(yè)務(wù)參數(shù)來做hash，以保證同一個瀏覽器用戶的請求落在同一個web服務(wù)器上。

優(yōu)點(diǎn)：只需要改nginx配置，不用改應(yīng)用代碼，負(fù)載均衡，只要hash屬性是均勻的，多臺web服務(wù)器是均衡的?？梢灾С謜eb服務(wù)器水平擴(kuò)展

缺點(diǎn)：如果web服務(wù)器重啟，一部分session會丟失，產(chǎn)生業(yè)務(wù)影響，例如部分用戶重新登陸。如果web服務(wù)器水平擴(kuò)展，rehash后session重新分布，也會有一部分用戶路由不到正確的session。

（4）服務(wù)器端集中存儲

將session存儲在后端的存儲層，如：數(shù)據(jù)庫或者緩存?？蛻舳嗣堪l(fā)一次請求，都會從存儲中獲取 ，再處理具體的業(yè)務(wù)邏輯。

優(yōu)點(diǎn)：無安全隱患，可以水平擴(kuò)展，服務(wù)器重啟或者擴(kuò)容都不會造成session丟失。

不足：增加了一次網(wǎng)絡(luò)調(diào)用，要修改應(yīng)用代碼。

總結(jié)：一般對于單點(diǎn)登錄和session共享的處理，大都選擇在服務(wù)端集中存儲來實(shí)現(xiàn)。對于db存儲還是cache，肯定cache是首選。因?yàn)閟ession讀取的頻率很高，使用數(shù)據(jù)庫壓力會比較大。如果有session高可用需求，cache可以做高可用，但大部分情況下session可以丟失，一般也不需要考慮高可用。目前主流的實(shí)現(xiàn)方案是用redis實(shí)現(xiàn)session的存儲。

4.分布式環(huán)境下的事務(wù)處理方案

對于分布式事務(wù)來說，事務(wù)的每個操作步驟是運(yùn)行在不同機(jī)器上的服務(wù)的。本質(zhì)上說，分布式事務(wù)是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

事務(wù)的ACID特性：原子性，一致性，隔離性，持久性。

解決方案：

（1）消息事務(wù)+最終一致性

消息事務(wù)就是基于消息中間件的兩階段提交，本質(zhì)上是對消息中間件的一種特殊利用，它是將本地事務(wù)和發(fā)消息放在了一個分布式事務(wù)里，保證要么本地操作成功并且對外發(fā)消息成功，要么兩者都失敗。以支付寶轉(zhuǎn)賬到余額寶為例，當(dāng)支付寶賬戶扣除1萬后，只要生成一個憑證（消息）即可，這個憑證（消息）上寫著“讓余額寶賬戶增加1萬“，只要這個憑證能可靠保存，我們最終是可以拿著這個憑證讓余額寶賬戶增加1萬的，即我們能依靠這個憑證完成最終一致性。

（2）TCC編程模式

TCC提供了一個編程框架，將整個業(yè)務(wù)邏輯分為三塊：Try,Confirm和Cancel 三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進(jìn)入Cancel階段，會去恢復(fù)庫存?？傊?，TCC就是通過代碼人為實(shí)現(xiàn)了兩階段提交，不同的業(yè)務(wù)場景所寫的代碼都不一樣，復(fù)雜度也不一樣，因此，這種模式并不能很好地被復(fù)用。

5.Zookeepeer的原理及選舉機(jī)制

Zookeeper是一個分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個開源的實(shí)現(xiàn)，它是集群的管理者，監(jiān)視著集群中各個節(jié)點(diǎn)的狀態(tài)根據(jù)節(jié)點(diǎn)提交的反饋進(jìn)行下一步合理操作。Zookeeper 可以作為服務(wù)協(xié)調(diào)的注冊中心，還可以做分布式鎖。它作為注冊中心，主要存儲的數(shù)據(jù)是ip，端口，還有心跳機(jī)制。

Zookeeper做集群做好是奇數(shù)個，她的集群管理主要檢查是否有機(jī)器的退出和加入，選舉maste。Zookeeper的角色主要分為：Leader,Follower,Observer.Leader主機(jī)負(fù)責(zé)讀和寫，F(xiàn)ollower負(fù)責(zé)讀，并將寫操作轉(zhuǎn)發(fā)給Leader,Follower還參與Leader選舉投票。Observer充當(dāng)觀察者的角色，不參與投票。當(dāng)Leader不可用時，會重新選舉Leader。超過半數(shù)的Follower選舉投票即可。

6.使用Redis做緩存有哪些優(yōu)勢

Redis是內(nèi)存式緩存，它的存取是純內(nèi)存操作，因此性能非常出色，每秒可處理超過1 0萬次讀寫，它的優(yōu)勢如下：

a內(nèi)存式緩存，讀寫速度特別快；

b支持豐富的數(shù)據(jù)類型：String, list ,set, sorted set,hash;

c支持事務(wù)，操作都是原子性，所謂原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行；

d豐富的特性：可用于緩存，消息，按key設(shè)置過期時間，過期后自動清除；

線程，單進(jìn)程，采用IO多路復(fù)用技術(shù);

7.分布式系統(tǒng)中如何生成唯一ID

1）數(shù)據(jù)庫自增長序列實(shí)現(xiàn)

優(yōu)點(diǎn)：a簡單代碼方便，性能可以接受。

b數(shù)字ID天然排序，對分頁或者需要排序的結(jié)果很有幫助；

缺點(diǎn)：

a不同數(shù)據(jù)庫語法和實(shí)現(xiàn)不同，數(shù)據(jù)庫遷移的時候或多數(shù)據(jù)庫版本支持的時候需 b要處理；

c在單個數(shù)據(jù)庫或讀寫分離或一主多從的情況下，只有一個主庫可以生成，有單點(diǎn)故障的風(fēng)險

d在性能達(dá)不到要求的情況下，比較難于擴(kuò)展；

e如果遇見多個系統(tǒng)需要合并或者涉及到數(shù)據(jù)遷移會相當(dāng)復(fù)雜；

f分表分庫的時候會麻煩；

2）通過UUID實(shí)現(xiàn)

可以利用數(shù)據(jù)庫也可以利用程序生成

優(yōu)點(diǎn)A簡單，代碼方便

B基本不會有性能問題

C全球唯一，在遇見數(shù)據(jù)遷移，系統(tǒng)數(shù)據(jù)合并，或者數(shù)據(jù)庫變更等情況下，可以從容應(yīng)對。

缺點(diǎn)：

A沒有排序，無法保證趨勢遞增。

B UUID往往使用字符串存儲，查詢的效率比較低

C存儲空間比較大，如果是海量數(shù)據(jù)庫，就需要考慮存儲量的問題了

D傳輸數(shù)據(jù)量大，不可讀。

3）Redis生成ID

當(dāng)使用數(shù)據(jù)庫來生成ID性能不夠要求的時候，可以使用Redis來生成ID。這主要依賴于Redis是單線程的，所以也可以生成全局唯一的ID?？梢杂肦edis的原子操作INCR和INCRBY來實(shí)現(xiàn)。可以使用Redis集群來獲取更高的吞吐量。假如一個集群中有5臺Redis,可以初始化每臺Redis的值分別是1,2,3,4,5；然后步長都是5.各個Redis生成的ID為：

A:1,6,11,16,21

B: 2,7,12,17,22

C:3,8,13,18,23

D:4,9,14,19,24

E:5,10,15,20,25

優(yōu)點(diǎn)：

A不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

B數(shù)字ID天然排序，對分頁或者需要排序的結(jié)果很有幫助。

缺點(diǎn)：

A如果系統(tǒng)中沒有Redis,還需要引入新的組件增加系統(tǒng)復(fù)雜度。

B需要編碼和配置的工作量比較大。

4）Twitter的snowflake算法

? ? Snowflake是Twitter開源的分布式ID生成算法，結(jié)果是一個long型的ID。其核心思 想是：使用41bit作為毫秒數(shù)，10bit作為機(jī)器的ID(5個bit是數(shù)據(jù)中心，5個bit的機(jī) ??? 器ID),12bit作為毫秒內(nèi)的流水號（意味著每個節(jié)點(diǎn)在每毫秒可以產(chǎn)生4096個ID）, 最后 ?? 還有一個符號位，永遠(yuǎn)是0。

? ? Snowflake算法可以根據(jù)自身項(xiàng)目需要進(jìn)行一定的修改，比如估算未來的數(shù)據(jù)中心個數(shù)，每個數(shù)據(jù)中心的機(jī)器數(shù)以及統(tǒng)一毫秒可以并發(fā)數(shù)來調(diào)整在算法中所需要的bit數(shù)。

優(yōu)點(diǎn)；

A不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

B ID按照時間在單機(jī)上遞增的

缺點(diǎn)；

A在單機(jī)上是遞增的，但是由于涉及到分布式環(huán)境，每臺機(jī)器上的時鐘不可能完 全同步，也許有時候也會出現(xiàn)不是全局遞增的情況。