一.?CAP理論慌核，BASE理論?
CAP:
C：強(qiáng)一致性，保證每一節(jié)點(diǎn)(微服務(wù))統(tǒng)一時(shí)間點(diǎn)數(shù)據(jù)的完全一致
A：可用性，整個(gè)系統(tǒng)是一直可用的,而且是正常響應(yīng)時(shí)間。不允許出現(xiàn)用戶訪問失敗的情況
P：分區(qū)容錯(cuò)性概荷，某一個(gè)節(jié)點(diǎn)或者網(wǎng)絡(luò)分區(qū)發(fā)生故障時(shí)，整個(gè)系統(tǒng)還是可用的碌燕，對于用戶來說沒有影響
注意：CAP理論就是說在分布式存儲(chǔ)系統(tǒng)中误证，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。P一定要實(shí)現(xiàn)修壕，所以就是CP和AP的權(quán)衡愈捅。
BASE:
BA：基本可用，系統(tǒng)出現(xiàn)問題慈鸠，用戶的響應(yīng)時(shí)間增加了蓝谨，或者非核心功能不可用了。都是可以的青团。
S：軟狀態(tài)譬巫，數(shù)據(jù)同步允許有延遲，這一段延遲的狀態(tài)就是軟狀態(tài)壶冒。
E：數(shù)據(jù)最終一致性缕题，在經(jīng)過一段時(shí)間的數(shù)據(jù)同步后，最終能達(dá)到一直就行胖腾，不要求實(shí)時(shí)烟零。
總結(jié)：cap是最理想化的,base是對cap的一些理解,更加現(xiàn)實(shí)化,是對cap的妥協(xié)瘪松。
二.?負(fù)載均衡算法，類型?
算法:
輪詢法锨阿；加權(quán)輪詢法
隨機(jī)法宵睦；加權(quán)隨機(jī)法
源地址哈希法：根據(jù)客戶端ip地址，通過哈希計(jì)算得到一個(gè)數(shù)值墅诡，對服務(wù)器列表進(jìn)行取模壳嚎，得到的結(jié)果就是要訪問的服務(wù)器的序號。
可以保證同一個(gè)ip地址的客戶末早，每次請求都會(huì)映射到指定的服務(wù)器.
最小連接數(shù)法：比較靈活和智能烟馅，比如A服務(wù)器有5個(gè)鏈接，B有3個(gè)然磷，C沒有鏈接郑趁。下次請求就會(huì)進(jìn)入C服務(wù)器。
類型:
DNS實(shí)現(xiàn)的負(fù)載均衡：訪問一個(gè)域名姿搜，映射到不同的ip地址
硬件負(fù)載均衡：F5和A10
軟件負(fù)載均衡： Nginx寡润，HAproxy，LVS等
三.分布式架構(gòu)下,session共享有什么方案?
使用jwt
使用cookie?(有安全風(fēng)險(xiǎn))
服務(wù)器之間進(jìn)行session同步：保證每個(gè)服務(wù)器都有session信息舅柜，消耗比較大梭纹。
ip綁定策略：比如使用Ngnix進(jìn)行源地址哈希法的負(fù)載均衡，讓每一個(gè)ip固定訪問一個(gè)服務(wù)器致份， 但是這種就失去分布式的作用变抽。
使用redis存儲(chǔ)：是業(yè)界最廣泛的。 可實(shí)現(xiàn)不同服務(wù)知举，不同平臺(tái)(網(wǎng)頁/app)瞬沦，甚至不同語言的session共享。
四.?分布式id生成方案?
UUID：時(shí)間戳+時(shí)鐘序列(計(jì)數(shù)器)+唯一的IEEE機(jī)器識(shí)別碼(比如網(wǎng)卡的MAC地址)
對數(shù)據(jù)庫不友好雇锡，因?yàn)殡S機(jī)不連續(xù)逛钻。mysql的主鍵默認(rèn)使用聚集索引，造成索引不連續(xù)
數(shù)據(jù)庫自增：對于數(shù)據(jù)庫集群模型锰提，要設(shè)置不同的數(shù)據(jù)庫起始值不同曙痘，但是步長(自增幾)相同。
Leaf-segment：(美團(tuán)大眾點(diǎn)評的)采用每次獲取一個(gè)ID區(qū)間的方式立肘。
比如一次和數(shù)據(jù)庫的交互边坤， 就請求到100個(gè)id，數(shù)據(jù)來了直接用谅年。避免每次添加數(shù)據(jù)都請求一個(gè)id茧痒，增加了數(shù)據(jù)庫的壓力。 也是對數(shù)據(jù)庫自增策略的一個(gè)優(yōu)化融蹂。
雪花算法(最流行)
snowflake是Twitter開源的分布式ID生成算法旺订，結(jié)果是一個(gè)長度為64bit的long型的ID弄企。
其核心思想是：41位時(shí)間戳+10位機(jī)器id+12位序列號+符號位(0)。? 12bit作為毫秒內(nèi)的流水號区拳，就是說每個(gè)節(jié)點(diǎn)在每毫秒可以產(chǎn)生4096 個(gè)ID拘领，并且是趨勢遞增的。
這樣適合于Mysql的聚集索引樱调，因?yàn)橼厔葸f增约素。索引的連續(xù)性好。
缺點(diǎn)：依賴于時(shí)間戳笆凌，時(shí)間戳是根據(jù)機(jī)器的時(shí)間得到的圣猎。比如linux中，如果人為的進(jìn)行時(shí)鐘回?fù)芷杏保涂赡茉斐蒳d重復(fù)样漆。
五.如何實(shí)現(xiàn)接口的冪等性?
接口冪等性就是用戶對于同一操作發(fā)起的一次請求或者多次請求的結(jié)果是一致的,，不會(huì)因?yàn)槎啻吸c(diǎn)擊而產(chǎn)生了副作用晦闰。比如注冊，支付時(shí)鳍怨，不會(huì)因?yàn)槎啻吸c(diǎn)擊產(chǎn)生不正確的結(jié)果呻右。
mysql 的唯一索引：比如注冊，設(shè)置賬號唯一鞋喇，多次插入時(shí)就不會(huì)成功声滥。但是需要每次操作數(shù)據(jù)庫，不好
token機(jī)制：服務(wù)器在訪問接口前就傳給用戶一個(gè)特定token并且保存在redis侦香，訪問接口帶上該token落塑， 判斷是否是第一次，是的話允許操作罐韩，完成邏輯后刪除token憾赁；不是的話不允許操作。
redis的setnx命令：如圖
版本控制：加樂觀鎖散吵，對于update時(shí)常用龙考。
狀態(tài)控制：例如訂單的狀態(tài)有已支付，未支付矾睦，支付中晦款，支付失敗等。只有處于未支付的時(shí)候才允許修改為支付中
