java學習記錄 · php筆記

## java學習記錄 **author: xiak** **last update: 2021-12-20 10:11:11** ---- [TOC=3,8] ---- ### 集群 #### 什么是集群集群通常是由**一個地域的數據中心的N臺機器組成**的一組**統一對外提供服務**的服務器群，每臺服務器就是最普通的單點服務器（單點應用），每臺機器的外網IP不同，既可以單獨提供服務，又能作為一個整體提供服務，集群內通過協調機制保持同步。通常一個數據中心的機器都在內網中，所以**一個集群內的機器間通信可以走內網**。（如果一個地域數據中心創建多個集群，多個集群間的通信也可以走內網。只要在同一個數據中心內都可以走內網。） ---- #### 為什么要集群受物理硬件等客觀限制，單臺服務器的承載能力總會有極限，無論是內存還是磁盤，或是來自軟件方面的限制（linux 每個進程可打開的資源等限制），并且單臺服務器容易出現單點故障。所以大的應用最終都會走向集群模式。 ---- #### 地域集群通常一個數據中心一個集群，如騰訊云-深圳1區集群，阿里云-北京A區集群等等。對外服務時都是同一個域名和端口，通過 DNS **負載均衡** 和 **就近分配**，如河北的用戶訪問就被分配到北京阿里云的集群了，四川的用戶訪問就被分配到深圳騰訊云的集群了。集群也可以跨地域機房，比如北京和深圳的共同組成一個集群，但是通常不會這樣做，因為這樣不能利用同一集群內**內網訪問速度的優勢**，完全沒必要跨機房組集群。可以一個地域一個集群，然后集群間跨地域數據同步即可。 ---- #### 集群DNS 集群內的機器不直接對外暴露IP，而是由集群整體暴露一個統一的域名，用戶并不關心當前訪問是由集群內哪臺機器提供服務的，以及集群有多少臺機器，根據負載情況動態增減調整集群內的機器數量，這對上層用戶來說是透明不可見的。當服務無狀態時，整個應用就是分布式架構的了。 ---- #### 集群災備通常一份數據會保留三份，兩份作為備份，以便在出現故障時恢復數據，最大程度上保證系統可用。**災備副本必須在不同的數據中心，即不同的集群。** 因為數據與災備在同一個數據中心、同一個機房就沒意義作為備份的意義了，數據中心或者機房失火，全部都燒了，哪怕數據在不同機器上也沒用，都燒光了，所以災備在不同的數據中心才有意義。（負載均衡節點充當了反向代理角色，起轉發流量作用） [容錯，高可用和災備 - 阮一峰的網絡日志](https://www.ruanyifeng.com/blog/2019/11/fault-tolerance.html) 上面三個方面可以結合起來，設計一個可靠的系統。 - 容錯：發生故障時，如何讓系統繼續運行。 - 高可用：系統中斷時，如何盡快恢復。 - 災備：系統毀滅時，如何搶救數據。 [什么是 Docker | Docker 從入門到實踐](https://vuepress.mirror.docker-practice.com/introduction/what/) [OS-level virtualization - Wikipedia](https://en.wikipedia.org/wiki/OS-level_virtualization) > 容器中虛擬了操作系統，而虛擬機則是虛擬了硬件系統。注意是操作系統級別的虛擬化，而不是應用軟件層的虛擬化。相當于系統上又起了很多輕量級系統（容器），要知道這些容器的操作系統本質上其實也是進程，底層與硬件交互的宿主操作系統還是一個，所以開銷比虛擬機低很多。 ---- #### 應用節點部署單點應用通常是一臺服務器上部署了應用，也啟動了mysql redis 等服務，所以可以看作是一臺服務器上部署了一個應用節點，一個 mysql 節點，一個 redis 節點。集群模式下通常不會讓一臺機器部署多種節點，而是根據服務器配置不同，有針對性的專門部署節點，如一個由10臺服務器組成的集群，可能會用5臺性能比較好的拿出來專門部署應用，3臺磁盤IO比較強的專門部署 mysql，2臺內存比較大的專門部署 redis ，這樣就是 5個應用節點，3個mysql節點，2個redis節點。更進一步，甚至一整個數據中心的集群全部用來專門部署一種節點，如 mysql 集群，redis 集群。 ---- #### 云服務器在地域下面，創建一個實例，就是一臺云服務器 CVM （Cloud Virtual Machine）。地域下還有可用區（隨機可用區、上海二區、上海三區、上海四區、上海五區）所以云服務器實例的地域：上海四區 IP地址默認有一個公網IP、一個內網IP，域名解析解析到公網IP上就可以做WEB節點了。那如果有多臺實例用一個域名怎么動態解析呢，怎么實現就近訪問，負載均衡呢？ > 可用區：**每個可用區都是獨立的數據中心**，可用區之間電力和網絡設備互相獨立，網絡互通，適合部署同城多活的高可用業務， **同一可用區內的主機網絡延時更小**。（北京3區-B、上海1區-A、廣東2區-A） ~~~ 區域及可用區區域根據數據中心地理位置劃分，不同區域間內網隔離，不能互相訪問。可用區一個區域包括多個可用區，每個可用區都相互獨立但網絡互通，同一可用區內的主機網絡延時更小。如果業務需要同城多活，建議您部署在不同可用區。詳情請參考：區域與可用區文檔 https://docsv3em.qingcloud.com/operation/resource/manual/region/area_resource/。常見問題 1.如何選擇區域？建議靠近您的業務區域選擇區域，可以減少網絡時延，提高訪問速度。另外，不同區域的資源價格可能有差異，您可以根據價格選擇合適的區域。 2.如何選擇可用區？每個可用區都相互獨立，規格相同。如果您初次創建資源，您可選擇系統分配。如果您的業務需要同城多活，建議您將主機部署在不同可用區，通過同一個負載均衡器對外提供服務。如果您的云服務器之間需要較低的網絡時延，則建議您將它們部署在相同的可用區內。 3.不同區域或不同可用區的云服務器是否可以通過內網相互訪問？不同區域的云服務器內網互不相通，如果有訪問需求，您可以通過綁定公網IP通過公網相互訪問或通過隧道服務訪問。同區域內不同可用區的云服務器如果處在同一個多可用區部署的私有網絡下，可以內網互通。 ~~~ ---- #### 負載均衡 [實例管理 - 負載均衡 - 控制臺](https://console.cloud.tencent.com/clb/instance?rid=4) [負載均衡產品概述 - 產品簡介 - 文檔中心 - 騰訊云](https://cloud.tencent.com/document/product/214/524) > 為提供更加彈性、穩定、高質量的服務，從2021年11月2日00:00:00起，所有負載均衡實例將進行架構升級，升級后提供并發連接數5萬，每秒新建連接數5000，每秒查詢數（QPS）5000 的性能保障。全新架構的負載均衡內網、外網實例價格將定為0.2元/小時(部分地域為0.3元/小時） ~~~ 負載均衡（Load Balancer，簡稱LB）提供安全快捷的流量分發服務，來自多個公網地址的訪問流量經由 LB 可以自動分配到多臺云服務器上，并支持自動檢測并隔離故障云服務器，提供業務系統的服務能力和可用性。負載均衡支持千萬級別并發訪問請求，可輕松應對大流量訪問，滿足業務需求。 [負載均衡 | QingCloud 文檔](https://docsv3.qingcloud.com/network/loadbalancer/) ~~~ ---- #### 彈性網卡 [彈性網卡 - 文檔中心 - 騰訊云](https://cloud.tencent.com/document/product/576) ---- #### DNS 服務器（域名解析、DNS 解析） [1.1.1.1 — The free app that makes your Internet faster.](https://1.1.1.1/) [Cloudflare推出最快公共DNS服務1.1.1.1，速度遠超8.8.8.8](https://mp.weixin.qq.com/s/rZwwi2iG9ULXNuFOUbZtvQ?) [系統狀態 - DNSPod 服務與支持](https://support.dnspod.cn/status/) [DNS.TECH 網站域名解析免費檢測工具 - 網絡撥測_故障診斷_網站備案 - 騰訊云 DNSPod](https://dns.tech/baidu.com) ~~~ DNS 服務商 ns2.baidu.com ns3.baidu.com ns4.baidu.com ns1.baidu.com ns7.baidu.com ~~~ ~~~ DNS 服務商已使用騰訊云 DNSPod 域名解析服務收起 f1g1ns1.dnspod.net f1g1ns2.dnspod.net (北京市 162.14.25.230 162.14.24.230 解析時間平均在 32ms 左右) （免費版負載均衡2 條） DNS 服務商解析結果解析記錄正常收起 A 212.64.100.122 NS f1g1ns2.dnspod.net. NS f1g1ns1.dnspod.net. SOA freednsadmin.dnspod.com. 1550299945 3600 180 1209600 180 Dig 詳情 Public DNS 解析結果解析記錄正常收起 A xxx.xxx.xxx.xxx NS f1g1ns2.dnspod.net. NS f1g1ns1.dnspod.net. SOA freednsadmin.dnspod.com. 1550299945 3600 180 1209600 180 ~~~ > 域名解析（DNS 解析）一個域名只能解析到一個IP，因為 A記錄主機名不能重復解析。可以？還真可以？那這樣到底請求那個IP啊，自帶負載均衡？在創建第三個相同的 A記錄使提示 “子域名負載均衡數量超出限制”，看來確實有負載均衡的功效啊，不過免費的默認最大只能兩個。 [負載均衡之DNS域名解析,實現一個域名對應多個IP地址_adsadadaddadasda的博客-CSDN博客_一個dns對應多個ip](https://blog.csdn.net/adsadadaddadasda/article/details/82902618) > 次*域名解析*請求都會根據對應的負載均衡算法計算出一個不同的IP地址并返回,這樣*A*記錄中配置多個服務器就可以構成一個集群,并可以實現負載均衡。 > 事實上，大型網站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務器并不是實際提供服務的物理服務器，而是同樣提供負載均衡服務器的內部服務器，這組內部負載均衡服務器再進行負載均衡，請請求發到真實的服務器上，最終完成請求。 [網站測速|網站速度測試|網速測試|電信|聯通|網通|全國|監控|CDN|PING|DNS 17CE.COM](http://17ce.com/site) [Query:?www.baidu.com -?Google Public DNS](https://dns.google/query?name=www.baidu.com) ~~~ { "Status": 0 /* NOERROR */, "TC": false, "RD": true, "RA": true, "AD": false, "CD": false, "Question": [ { "name": "www.baidu.com.", "type": 1 /* A */ } ], "Answer": [ { "name": "www.baidu.com.", "type": 5 /* CNAME */, "TTL": 1059, "data": "www.a.shifen.com." }, { "name": "www.a.shifen.com.", "type": 5 /* CNAME */, "TTL": 184, "data": "www.wshifen.com." }, { "name": "www.wshifen.com.", "type": 1 /* A */, "TTL": 232, "data": "103.235.46.39" } ] } ~~~ [DNS 原理入門 - 阮一峰的網絡日志](http://www.ruanyifeng.com/blog/2016/06/dns.html) ---- #### CDN 內容分發網絡 [內容分發網絡 CDN - 文檔中心 - 騰訊云](https://cloud.tencent.com/document/product/228) ---- #### 在云上部署集群以騰訊云為例，我們在騰訊云上使用 pulsar ： 1. 進入消息隊列 TDMQ - 控制臺，首先地域已默認上海（云上的所有資源，都是在某個地域下） 2. 點擊創建按鈕，創建一個集群： ~~~ 集群類型：虛擬集群（默認，只有這一個選項）使用虛擬化的計算和存儲資源，根據用量自動分配，使用有一定限制，無需為資源付費單個主賬號最多創建5個虛擬集群集群類型：虛擬集群: 使用虛擬化的計算和存儲資源，根據用量自動分配，使用有一定限制，無需為資源付費，每個用戶最多可以創建5個虛擬集群。專享集群: 獨占物理資源，數據安全，使用幾乎無限制，未達到使用要求會額外計算資源占用費。 ~~~ 3. 操作兩次，我們就在上海下創建了兩個集群，注意創建集群時并沒有指定集群內要多少臺機器，因為是虛擬化的，自動分配的。 ~~~ 上海華東地區 j1 http://pulsar-jebg245o53m2.tdmq-pulsar.ap-sh.qcloud.tencenttdmq.com:5039 http://pulsar-jebg245o53m2.tdmq-pulsar.ap-sh.public.tencenttdmq.com:8080 j2 http://pulsar-jze7or9kdow7.tdmq-pulsar.ap-sh.qcloud.tencenttdmq.com:5039 http://pulsar-jze7or9kdow7.tdmq-pulsar.ap-sh.public.tencenttdmq.com:8080 廣州華南地區 j1 http://pulsar-24k5nwqd8ko5.tdmq.ap-gz.qcloud.tencenttdmq.com:5035 新加坡亞太東南 j1 http://pulsar-9nprpeo9jga7.tdmq.ap-sg.qcloud.tencenttdmq.com:5000 ~~~ 這樣我們有了三個地區的總共4個集群。從 **VPC 內網接入地址** 我們可以看到集群 id 不同，`ap-sh` `ap-gz` `ap-sg` 地域也不同，還有不同地域端口也不同，其它基本都是相同的。（VPC 內網接入地址和公網接入地址基本也是一樣的）在同一個地域的多個集群可看作是**同城多活**。不同地域的多個集群可看作是**異地多活**。默認只開放了內網，那臺上海地域的云服務器實例可以用 VPC 內網接入地址訪問上海的 pulsar 集群。 topic: `pulsar-jebg245o53m2/name/topic` 集群id / 命名空間 / topic，可以看到 **pulsar 的租戶就是騰訊云這里的集群**了，**租戶/集群間是相互完全隔離和獨立的，租戶/集群間沒有任何關系**。**消息是屬于某個集群下的一個命名空間下的**，配置權限也是在命名空間上。 pulsar 租戶可以跨集群分布，騰訊云不支持這一點。[多租戶 · Apache Pulsar](https://pulsar.apache.org/docs/zh-CN/next/concepts-multi-tenancy/) [消息隊列 Pulsar 版集群管理 - 操作指南 - 文檔中心 - 騰訊云](https://cloud.tencent.com/document/product/1179/52145) 或者說騰訊云去掉了租戶這一層的概念。因為對騰訊云來說，我們是他的客戶，也是他pulsar平臺的一個租戶。 > 集群是 TDMQ Pulsar 版中的一個資源維度，不同集群的命名空間、Topic、角色權限等完全隔離。每個集群會有集群的資源限制例如 Topic 總數、消息保留時長等。常見的使用方式如：開發測試環境使用一個專門集群，生產環境使用一個專門的集群。 ---- ### pulsar #### 客戶端設置步驟在應用程序創建生產者/消費者之前，Pulsar 客戶端庫需要啟動一個設置階段，包括兩個步驟： 1. **客戶端將嘗試通過向服務器（Broker）發送 HTTP 查找請求**，來確定主題（Topic）所在的服務器（Broker）。客戶端通過查詢 ZooKeeper 中 (緩存) 的元數據，來確定這條消息的 topic 在哪個 broker 上，如果該 topic 不在任何一個 broker 上，則把這個 topic 分配在負載最少的 broker 上。 2. 當客戶端獲取了broker的地址之后，**將會創建一個TCP連接** (或復用連接池中的連接) 并且進行鑒權。客戶端和broker通過該連接交換基于自定義協議的二進制命令。同時，客戶端會向broker發送一條命令用以在broker上創建生產者/消費者，該命令將會在驗證授權策略后生效。每當 TCP 連接中斷時, 客戶端將立即重新啟動上述步驟的設置階段, 并將繼續嘗試使用指數退避重新建立生產者或消費者, 直到上述步驟執行成功為止。這個過程可以以描述為： 1. 不論是創建生產者/消費者，都攜帶參數 topic ，http 請求任意一臺 Broker http 服務器以獲取 topic 所在的 broker 服務器地址。 2. tcp 連接這個 broker 服務器地址，向其發送創建生產者/消費者的命令。 Broker 是無狀態的，所以第一步 http 請求任意一臺 Broker 服務器都可以（**這就是分布式系統的特點，節點是無狀態的，客戶端請求任意節點都可以，任意節點都能提供相同的服務**），不過客戶端肯定最好不要使用具體的 host ip 地址，而應該使用域名 DNS 的方式，這樣避免了單點問題，而且用IP硬編碼不靈活，并且有 DNS 還能起到負載均衡的效果。不過這樣每次創建生產者/消費者都需要請求兩次，第一次 http 請求 **查詢 topic 所在 Broker 服務器**，如果能去掉這一步就好了。但不能，因為必須要路由到有 topic 的 Broker 才行，系統是分布式的，客戶端不知道資源應該由哪個節點處理，所以這一步是少不了的。除非客戶端直接與一個代理進行交互，不用關心資源所在的 Broker。只能說現階段這樣不好，增加了客戶端的復雜度，應該使路由資源這一步對客戶端不可見透明才好。 > 無法做到只提供一個節點給客戶端，讓這一路由過程對客戶端不可見，因為這恰好是分布式系統的特點，這樣才能提高吞吐，否則單點代理也會成為吞吐的瓶頸。所以分布式系統無法讓客戶端保持輕量，傳統 redis mysql 太輕量了，一個簡單的 tcp 客戶端就行了，所以也只能做簡單的事。 > apache-pulsar-2.9.1-src.tar.gz 用 360解壓會有問題，缺少文件或者路徑被截斷了，可能是目錄層級太多了，文件名不能過長了，所以使用 tar 命令解壓，不要使用 360解壓。 [裸機多集群部署 · Apache Pulsar](https://pulsar.apache.org/docs/zh-CN/next/deploy-bare-metal-multi-cluster/) [zookeeper 集群搭建 - YSOcean - 博客園](https://www.cnblogs.com/ysocean/p/9860529.html) > zookeeper 節點數量必須是奇數