java--那些事-創(chuàng)新互聯(lián)

1、為什么Controller層注入的是Service接口，而不是ServiceImpl實(shí)現(xiàn)類
Controller層
@Autowired
private TestImpl?testImpl; //注入了實(shí)現(xiàn)類

創(chuàng)新互聯(lián)長期為1000多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為遵義企業(yè)提供專業(yè)的網(wǎng)站制作、做網(wǎng)站，遵義網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

面向接口編程

? (1）注入的就是實(shí)現(xiàn)類，只不過拿接口來接收，接收的類型為接口，面向接口編程，那么為何要面向接口編程？這就涉及到使用接口做代理，因?yàn)橥ㄟ^@autowired的對象是通過接口的方式會使用jdk動態(tài)代理，jdk動態(tài)代理只能對實(shí)現(xiàn)接口的類生成代理，而不能針對類。

? (2）注入的是實(shí)現(xiàn)類對象，接收的是接口；理解為多態(tài)；

要遵循Controller–Service接口–ServiceImpt實(shí)現(xiàn)類–Mapper接口模式;

2、分布式鎖三種實(shí)現(xiàn)方式
(1)、?基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖；
(2)、基于緩存（Redis等）實(shí)現(xiàn)分布式鎖；
(3)、?基于Zookeeper實(shí)現(xiàn)分布式鎖；

一、基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
1. 悲觀鎖

利用select … where … for update 排他鎖

注意: 其他附加功能與實(shí)現(xiàn)一基本一致，這里需要注意的是“where name=lock ”，name字段必須要走索引，否則會鎖表。有些情況下，比如表不大，mysql優(yōu)化器會不走這個索引，導(dǎo)致鎖表問題。

2. 樂觀鎖

所謂樂觀鎖與前邊大區(qū)別在于基于CAS思想，是不具有互斥性，不會產(chǎn)生鎖等待而消耗資源，操作過程中認(rèn)為不存在并發(fā)沖突，只有update version失敗后才能覺察到。我們的搶購、秒殺就是用了這種實(shí)現(xiàn)以防止超賣。
通過增加遞增的版本號字段實(shí)現(xiàn)樂觀

3：分布式鎖三種實(shí)現(xiàn)方式對比：

數(shù)據(jù)庫分布式鎖實(shí)現(xiàn)
缺點(diǎn)：

1.db操作性能較差，并且有鎖表的風(fēng)險
2.非阻塞操作失敗后，需要輪詢，占用cpu資源;
3.長時間不commit或者長時間輪詢，可能會占用較多連接資源

Redis(緩存)分布式鎖實(shí)現(xiàn)
缺點(diǎn)：

1.鎖刪除失敗過期時間不好控制
2.非阻塞，操作失敗后，需要輪詢，占用cpu資源;

ZK分布式鎖實(shí)現(xiàn)
缺點(diǎn)：性能不如redis實(shí)現(xiàn)，主要原因是寫操作（獲取鎖釋放鎖）都需要在Leader上執(zhí)行，然后同步到follower。

總之：ZooKeeper有較好的性能和可靠性。

從理解的難易程度角度（從低到高）數(shù)據(jù)庫 >緩存 >Zookeeper

從實(shí)現(xiàn)的復(fù)雜性角度（從低到高）Zookeeper >= 緩存 >數(shù)據(jù)庫

從性能角度（從高到低）緩存 >Zookeeper >= 數(shù)據(jù)庫

從可靠性角度（從高到低）Zookeeper >緩存 >數(shù)據(jù)庫

4、Kafka、RocketMQ、RabbitMQ的對比

RabbitMq

由于erlang語言的特性，mq 性能較好，高并發(fā)；
吞吐量到萬級，MQ功能比較完備；
健壯、穩(wěn)定、易用、跨平臺、支持多種語言、文檔齊全；
開源提供的管理界面非常棒，用起來很好用；
社區(qū)活躍度高；

缺點(diǎn)
erlang開發(fā)，很難去看懂源碼，基本職能依賴于開源社區(qū)的快速維護(hù)和修復(fù)bug，不利于做二次開發(fā)和維護(hù)；
RabbitMQ確實(shí)吞吐量會低一些，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重；
需要學(xué)習(xí)比較復(fù)雜的接口和協(xié)議，學(xué)習(xí)和維護(hù)成本較高；

RocketMQ:

優(yōu)點(diǎn)：
單機(jī)吞吐量：十萬級；
可用性：非常高，分布式架構(gòu)；
消息可靠性：經(jīng)過參數(shù)優(yōu)化配置，消息可以做到0丟失；
功能支持：MQ功能較為完善，還是分布式的，擴(kuò)展性好；
支持10億級別的消息堆積，不會因?yàn)槎逊e導(dǎo)致性能下降；
源碼是java，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控；

缺點(diǎn)
支持的客戶端語言不多，目前是java及c++，其中c++不成熟；
社區(qū)活躍度一般；
沒有在 mq 核心中去實(shí)現(xiàn)JMS等接口，有些系統(tǒng)要遷移需要修改大量代碼；

Kafka：

優(yōu)點(diǎn)：
性能卓越，單機(jī)寫入TPS約在百萬條/秒，大的優(yōu)點(diǎn)，就是吞吐量高；
時效性：ms級；
可用性：非常高，kafka是分布式的，一個數(shù)據(jù)多個副本，少數(shù)機(jī)器宕機(jī)，不會丟失數(shù)據(jù)，不會導(dǎo)致不可用；
消費(fèi)者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次;
有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager；
在日志領(lǐng)域比較成熟，被多家公司和多個開源項(xiàng)目使用；
功能支持：功能較為簡單，主要支持簡單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實(shí)時計算以及日志采集被大規(guī)模使用；

缺點(diǎn)：
Kafka單機(jī)超過64個隊(duì)列/分區(qū)，Load會發(fā)生明顯的飆高現(xiàn)象，隊(duì)列越多，load越高，發(fā)送消息響應(yīng)時間變長；
使用短輪詢方式，實(shí)時性取決于輪詢間隔時間；
消費(fèi)失敗不支持重試；
支持消息順序，但是一臺代理宕機(jī)后，就會產(chǎn)生消息亂序；
不支持延遲隊(duì)列
不支持死信隊(duì)列
社區(qū)更新較慢；

三者主要區(qū)別：

產(chǎn)品	建議
Kafka	Kafka主要特點(diǎn)是基于Pull的模式來處理消息消費(fèi)，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。大型公司建議可以選用，如果有日志采集功能，肯定是選kafka了。
RocketMQ	天生為金融互聯(lián)網(wǎng)領(lǐng)域而生，對于可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業(yè)務(wù)削峰，在大量交易涌入時，后端可能無法及時處理的情況。 RoketMQ在穩(wěn)定性上可能更值得信賴，這些業(yè)務(wù)場景在阿里雙11已經(jīng)經(jīng)歷了多次考驗(yàn)，如果你的業(yè)務(wù)有上述并發(fā)場景，建議可以選擇RocketMQ。
RabbitMQ	結(jié)合erlang語言本身的并發(fā)優(yōu)勢，性能較好，社區(qū)活躍度也比較高，但是不利于做二次開發(fā)和維護(hù)。不過，RabbitMQ的社區(qū)十分活躍，可以解決開發(fā)過程中遇到的bug。如果你的數(shù)據(jù)量沒有那么大，小公司優(yōu)先選擇功能比較完備的RabbitMQ。

5、分布式事務(wù)--》CAP理論和BASE理論

1）CAP理論
1998年，加州大學(xué)的計算機(jī)科學(xué)家 Eric Brewer 提出，分布式系統(tǒng)有三個指標(biāo)：

Consistency（一致性）
Availability（可用性）
Partition tolerance （分區(qū)容錯性）

CAP定理- Consistency
Consistency（一致性）：用戶訪問分布式系統(tǒng)中的任意節(jié)點(diǎn)，得到的數(shù)據(jù)必須一致
CAP定理- Availability
Availability （可用性）：用戶訪問集群中的任意健康節(jié)點(diǎn)，必須能得到響應(yīng)，而不是超時或拒絕

?CAP定理-Partition tolerance

Partition（分區(qū)）：因?yàn)榫W(wǎng)絡(luò)故障或其它原因?qū)е路植际较到y(tǒng)中的部分節(jié)點(diǎn)與其它節(jié)點(diǎn)失去連接，形成獨(dú)立分區(qū)。
Tolerance（容錯）：在集群出現(xiàn)分區(qū)時，整個系統(tǒng)也要持續(xù)對外提供服務(wù)

2）BASE理論
BASE理論是對CAP的一種解決思路，包含三個思想：

Basically Available （基本可用）：分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用性，即保證核心可用。
Soft State（軟狀態(tài)）：在一定時間內(nèi)，允許出現(xiàn)中間狀態(tài)，比如臨時的不一致狀態(tài)。
Eventually Consistent（最終一致性）：雖然無法保證強(qiáng)一致性，但是在軟狀態(tài)結(jié)束后，最終達(dá)到數(shù)據(jù)一致。

而分布式事務(wù)大的問題是各個子事務(wù)的一致性問題，因此可以借鑒CAP定理和BASE理論：

AP模式：各子事務(wù)分別執(zhí)行和提交，允許出現(xiàn)結(jié)果不一致，然后采用彌補(bǔ)措施恢復(fù)數(shù)據(jù)即可，實(shí)現(xiàn)最終一致。
CP模式：各個子事務(wù)執(zhí)行后互相等待，同時提交，同時回滾，達(dá)成強(qiáng)一致。但事務(wù)等待過程中，處于弱可用狀態(tài)

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

新聞標(biāo)題：java--那些事-創(chuàng)新互聯(lián)
分享鏈接：http://bm7419.com/article26/cecgcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、外貿(mào)建站、微信小程序、靜態(tài)網(wǎng)站、ChatGPT、App開發(fā)

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容