rocketmq怎麼配置六台機器連接
⑴ rocketmq 怎麼和我的系統整合
linux伺服器集群平台的搭建比較簡單，有專門的均衡軟體，比如lvs，lvs是一個集群系統，由很多伺服器組成，可以根據需要，把它門分為三層，一層是前端機，用於均衡，相當於公平為系統分配工作，二層是伺服器群，比如web伺服器群，DNS，mail群等，這些就是接待員，把均衡器分配的工作進行處理，第三層是存儲設備，用於存儲數據，相當於檔案庫。
知道這些後，要搭建就非常容易，有現成的軟體，比如我有四台web伺服器，2台資料庫，1台前置機 ，安裝linux系統，安裝lvs軟體，比如
heartbeat-2.1.4-9.el5.i386.rpm
heartbeat-ldirectord-2.1.4-9.el5.i386.rpm
libnet-1.1.4-3.el5.i386.rpm
heartbeat-devel-2.1.4-9.el5.i386.rpm
heartbeat-pils-2.1.4-10.el5.i386.rpm
perl-MailTools-1.77-1.el5.noarch.rpm
heartbeat-gui-2.1.4-9.el5.i386.rpm
heartbeat-stonith-2.1.4-10.el5.i386.rpm
當然還需要配置，你可以自己網路有關lvs集群的詳細安裝說明。希望能幫助你。
⑵ 軟體更新丨Spring Cloud Alibaba發布第二個版本，Spring發來賀電
還是熟悉的面孔，還是熟悉的味道，不同的是，這次的 配方升級 了。
時隔 51天，Spencer Gibb再次在Spring官網的博客頁面宣布：Spring Cloud Alibaba發布了其開源後的 第二個版本0.2.1 ，隨後，Spring Cloud 官方Twitter也轉發了此消息。聖誕節的前一周，Josh Long向他的老朋友許曉斌發來賀電：
視頻地址：https://spring.io/blog/2018/12/26/spring-tips-bootiful-alibaba
一、新版本概要
Spring Cloud Alibaba RocketMQ
Spring Cloud Alibaba SchelerX
Spring Cloud Alibaba Nacos Config
Spring Cloud Alibaba Nacos Discovery
Spring Cloud Alibaba Sentinel
二、新版本背後的思考
Spring Cloud Alibaba Nacos Discovery
Nacos Discovery 在這個版本最大的更新就是支持在初始化的時候不使用本地文件緩存，目前初始化的時候已經默認不使用本地文件緩存。
為什麼要有緩存？首先我們來了解一下本地緩存的概念，為什麼需要這個本地緩存？
我們都知道，服務注冊與發現應該只是服務調用中的輔助性的一個環節，而不是一個關鍵的環節。一個良好的服務注冊與發現的設計，需要保證以下兩點。
要實現以上兩點，緩存就不可或缺，而為了適應不同的場景，緩存又可以分成內存緩存和本地文件緩存，他們的概念和適用場景如下。
內存中的緩存
將服務提供者列表維護在內存中，每次調用時直接從內存中的列表獲取節點即可。內存緩存通過定時任務更新，或者在收到服務注冊中心的推送之後再更新。確保了即使在服務注冊中心宕機的情況下，也能保證服務仍能正常調用。
本地文件緩存
將上述提到的內存中的緩存，保留在本地的某個文件中，這樣在調用服務注冊中心失敗的時候，可以從本機的文件緩存中獲取服務提供者列表。這樣就保證了在服務注冊中心宕機的情況下，應用在重啟後也能找到服務提供者。
為什麼要關閉
有了以上背景知識後，讀者可能會有疑問，既然緩存這么好，你們為什麼默認要把它置為默認關閉呢？
我們在發布出第一個版本之後，很多用戶反饋，為什麼我服務下線之後還是有節點，仍舊可以被查詢到呢？這樣導致我這個監控數據完全不準，你們這個有 bug，完全不對。其實這是阿里巴巴在多年業務積累的經驗，對於服務發現來說，一個即使是已經過時的節點，也比沒有任何數據好。而且還有可能其實這個服務只是和服務注冊中心失去了心跳，但是應用本身是正常的。
當然，這也暴露了我們設計中存在的一些問題，沒有把服務發現本身，以及緩存的分層給做好，兩者糅合在一塊。所以在這一次的版本更新中我們還是選擇適配開源標准，默認關閉了本地文件緩存，留了一個開關給用戶自由選擇。
Spring Cloud Alibaba Nacos Config
Nacos Config 在這個版本中有兩個大的特性，支持了「共享配置」，修正了動態刷新的語義和行為。
共享配置的實現
在第一個版本還沒發布到時候，社區里對配置管理中心的討論就沒停止過，其中聽到最多的反饋應該就是支持多個應用共享一個配置。我們也通過 github issue 的方式，徵集了很多意見，詳情見 #12 , #141。
後來我們將這個模型抽象了一下，認清這些需求本質是一個應用可以從多個 DataID 和 GroupID 組合中獲取配置，並且這些配置還可以單獨指定優先順序和是否動態刷新。
最後我們推薦了這種使用方式，既保證了使用場景的靈活性，又保證了業務語義的明確性。更多詳情可以參考 WIKI。
注意 data-id 的值必須帶文件擴展名，文件擴展名支持 properties、yaml 和 yml。通過這種自定義擴展的配置項，既可以支持一個應用從多個配置項中獲取數據，也解決多個應用間配置共享的問題。
頭腦風暴，@fudali 同學還提出了更加靈活的一種方式 #161，就是可以通過一個配置項來配置所有的 DataID 的信息，然後可以通過修改這個配置項，可以修改整體配置項的邏輯。
這是一個非常好的想法，只不過這一期中我們沒有實現，原因是這種方式太靈活了。我們認為配置管理其實是一件很嚴肅的事情，太靈活導致生產中變更比較不可控。
雖然目前的邏輯也可以支持這種用法，但是我們並沒有把這種模式當做推薦模式，後續如果社區有更多的反饋認為這是一個強烈的需求，歡迎提 PR。
動態刷新的修正
簡單好用、實時可監控的動態刷新也許是 Nacos Config 相對於其他開源中間件相比最核心的優勢了，不同於 Spring Cloud Config Server 必須使用 Spring Cloud Bus 才能實現動態刷新，Nacos Config 無需依賴其他任何中間件就可以實現實時動態刷新，而且推送成功與否和刷新 歷史 還支持實時查詢。
但是我們發現在第一個版本中的實現發現兩個問題：
在這個版本中，我們修復了這兩個問題。
首先，動態刷新不再是直接去調用 ContextRefresher.refresh() 方法，而是 publish 了一個 RefreshEvent，讓 spring-cloud-commons 里的 RefreshEventListener 去觸發這個 ContextRefresher.refresh() 方法。
其次，我們修正了動態刷新的語義後，這一次是真正做到了，只有 refresh 屬性為 true 的配置項，才會在運行的過程中變更為新的值，refresh 屬性為 false 的配置項再也不用擔心應用在運行的過程中發生莫名其妙的變更了。
更深入一點，在上個月 SpringOne Tour 中，我們和 Spring Cloud 的創始人 Spencer 聊到 Spring Cloud 的 Context.refresh() 成本太高，會刷新整個 Spring Context。他反復強調了兩次 Context.refresh() 只對 @RefreshScope 和 @ConfigurationProperties 有效，成本一點也不高。
之前我們接收到很多社區的反饋都是 Nacos Config 動態刷新支不支持 xxxx，支不支持 xxxx。之前我們都是回答只支持 @RefreshScope 和 @ConfigurationProperties ，如果他內置沒有支持，那就得自己加上相應的註解。
今天我們可以很愉快地回復，他監聽了 RefreshEvent 也能直接支持。而且如果添加 @RefreshScope 和 @ConfigurationProperties 都不滿足你的需求時，可以通過實現自己的 RefreshEventListener 更多高級的玩法。
Spring Cloud Alibaba Sentinel
Sentinel 在這個版本中有三個大的特性：全面支持 FeignClient ，完善了 RestTemplate 的支持，添加了熱點限流、集群限流。
FeignClient 集成 Sentinel
其實在這之前，Sentinel 支持 FeignClient 已經設計了很久了，之前我們的想法做一個兼容性較強的方案，支持 Sentinel 和 Hystrix 在 FeignClient 中同時使用，盡量做到對原有應用的侵入性做到最小。
這個方案我們也思考調研了很久，但是實現難度確實比較大，需要修改 FeignClient 的代碼才能實現兩者共存。正好前段時間在 Spring Cloud 屆最大的新聞就是 Hystrix 宣布不在維護了，於是我們就換了一個思路，直接使用 Sentinel 替代 Hystrix，不再去追求支持兩者共存。
我們實現了自己的 Feign.Builder，在構建的 FeignClient 執行調用的過程中，通過 SentinelInvocationHandler 完成 Sentinel 的流量統計和保護的動作。如果想使用 Sentinel 為 FeignClient 限流降級，首先需要引入 sentinel-starter 的依賴，然後打開 Sentinel 限流降級的開關 feign.sentinel.enabled=true ，就完成了 Sentinel 的接入。如果需要使用更加定製化的功能，則需要在 @FeignClient 添加 fallback 和 configuration 這些屬性的配置。
注意 @FeignClient 註解中的所有屬性，Sentinel 都做了兼容。
RestTemplate 集成 Sentinel
Spring Cloud Alibaba Sentinel 支持對 RestTemplate 的服務調用使用 Sentinel 進行保護，補全了 Hystrix 這一塊的空白。接入的方式也不復雜，在構造 RestTemplate bean 的時候需要加上 @SentinelRestTemplate 註解，然後在控制台配置相應的規則即可。
在觸發了限流降級時，默認的處理方式是返回 RestTemplate request block by sentinel 信息。
RestTemplate 的限流降級 ？Sentinel 也承包了！
熱點參數限流和集群限流
首先解釋一下什麼是熱點參數限流和集群限流。
熱點參數限流會統計傳入參數中的熱點參數，並根據配置的限流閾值與模式，對包含熱點參數的資源調用進行限流。熱點參數限流可以看做是一種特殊的流量控制，僅對包含熱點參數的資源調用生效。
集群流控主要解決的問題是：當我們需要控制整個集群流量總量，但是單機流量可能會不均勻，如果是單機維度去限制的話會無法精確地限制總體流量，因此需要引入集群維度的流量控制。
Sentinel v1.4.0 的 新功能 ，也能第一時間愉快地在 Spring Cloud Alibaba 上使用了。
三、新組件
Spring Cloud Alibaba RocketMQ
Spring Cloud Stream 是一個用於構建基於消息的微服務應用框架，它基於 SpringBoot 來創建具有生產級別的單機 Spring 應用，並且使用 Spring Integration 與 Broker 進行連接。它提供了消息中間件的統一抽象，推出了 publish-subscribe、consumer groups、partition 這些統一的概念。
RocketMQ 是一款開源的分布式消息系統，基於高可用分布式集群技術，提供低延時的、高可靠的消息發布與訂閱服務。具有以下特點：能夠保證嚴格的消息順序、提供豐富的消息拉取模式、高效的訂閱者水平擴展能力、實時的消息訂閱機制、億級消息堆積能力。
在這次的 Spring Cloud Stream Binder RocketMQ 的實現中，我們適配了 Spring Cloud Stream 對於 message 抽象的 API，支持了 RocketMQ 的事務消息。消息訂閱時支持以 tags、SQL 表達式過濾消息，同時還支持順序、並發、延遲以及廣播消費模式。
Spring Cloud Alibaba SchelerX
SchelerX 是阿里中間件團隊開發的一款分布式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務，同時提供分布式的任務執行模型，如網格任務，網格任務支持海量子任務均勻分配到所有 Worker（schelerx-client）上執行。
簡單易用的輕量分布式任務調度
您不需要關心調度邏輯，只需要在在 JobProcessor 介面的實現中添加業務邏輯即可，然後在自主運維控制台配置上一個 Job 即可完成使用。
高可用的分布式任務
不管是 SchelerX 服務端還是客戶端都是分布式架構設計，任務可以在多台客戶端機器里的任何一台機器執行，如果客戶端出現宕機的情況，服務端會自動選擇正常運行的客戶端去執行 Job，每個 Job 在服務端的不同機器均有備份，SchelerX 服務端任意宕掉部分機器仍能保證 Job 正常調度。
友好的用戶界面
SchelerX 提供了非常友好的頁面方便您創建、刪除或修改 Job，提供了立即觸發執行一次的功能，方便您測試以及關鍵時刻手動立即執行一次，還提供了 歷史 執行記錄查詢的功能，您可以看到任何一個 Job 過去 100 次的 歷史 執行記錄。
功能強大
提供了秒級、精準的定時任務調度服務，且提供了豐富的任務執行模型，包括單機執行，廣播執行，以及子任務的分布式執行。
四、What's Next?
Spring Cloud Alibaba Cloud SLS 針對日誌類數據的一站式服務，在阿⾥巴巴集團經歷大量大數據場景錘煉⽽成。您⽆需開發就能快捷地完成日誌數據採集、消費、投遞以及查詢分析等功能，提升運維、運營效率，建立 DT 時代海量日誌處理能力。
Spring Cloud Alibaba Dubbo Dubbo 是一款流行的開源 RPC 框架，我們會把 Dubbo 整合到 Spring Cloud Alibaba 中，讓大家在開發 Dubbo 時也能享受到 Spring Cloud 帶來的便利。
致謝
Spring Cloud Alibaba 從開源建設以來，受到了很多社區同學的關注。社區的每一個 issue ，每一個 PR，都是對整個項目的幫助，都在為建設更好用的 Spring Cloud 添磚加瓦。
↓↓↓
⑶ 如何配置rockmq佔用內存的大小
典型JVM參數設置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：設置JVM用內存3550M
-Xms3550m：設置JVM促使內存3550m值設置與-Xmx相同避免每垃圾收完JVM重新配內存
-Xmn2g：設置輕代2G整堆=輕代 + 代 + 持久代持久代般固定64m所增輕代減代值系統性能影響較Sun官推薦配置整堆3/8
-Xss128k：設置每線程堆棧JDK5.0每線程堆棧1M前每線程堆棧256K更具應用線程所需內存進行調整相同物理內存減值能更線程操作系統進程內線程數限制能限經驗值3000~5000左右
java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:設置輕代（包括Eden兩Survivor區）與代比值（除持久代）設置4則輕代與代所佔比值1：4輕代占整堆棧1/5
-XX:SurvivorRatio=4：設置輕代Eden區與Survivor區比值設置4則兩Survivor區與Eden區比值2:4Survivor區占整輕代1/6
-XX:MaxPermSize=16m:設置持久代16m
⑷ 零基礎，自學能不能學懂Java
題主問能不能學懂Java，可以看出題主和很多小夥伴一樣，想學習Java但是聽說Java很難所以一直不敢嘗試。有句話叫做「萬事開頭難」，不管做任何事都要自己親身去嘗試去體驗去努力才知道究竟是怎樣的。為了解答題主和各位小夥伴的疑惑，那麼知了姐姐今天和大家聊聊Java究竟難在哪裡？或許看完知了姐姐的分析，你就知道自己能不能學懂Java了。
Java學習其實可以分為初、中、高三個學習階段，不同的學習階段有不同的難點。
第一階段：初級
面向對象：基本上大多數同學在學到這個概念的時候都會一臉懵逼，太抽象，邏輯思維不好的同學，掉到這個坑裡就不能自拔。
多線程：這個也是初級里比較難纏的章節，其實有些已經工作兩三年的同學，對這個現在也是一頭霧水，一知半解。但是有部分的初級程序員是接觸不到這方法開發工作的。
第二階段：中級
中級裡面裡面的知識點比較多，大概分為2種：
前端html css java
後台servlet jdbc
這個階段要學習的知識真的很多，學習起來，會覺得比較亂，學習起來也是比較吃力，但是把這個階段學習好的話，學習框架知識，就是很輕松的。
第三階段：高級
對於能夠學習到這塊的小夥伴，java對於他來說已經沒有難學的了，萬變不離其宗，只要把前面的知識掌握好，後面就會越來越簡單了。
萬事難就難在開頭，有的小夥伴還沒有開始就倒在了「helloworld」上面；有志者事竟成 ，有的小夥伴努力學習天天聯系，於是自學成功了認為：java 其實不是那麼困難的。
最後，知了姐姐再給還在猶豫的小夥伴分享一下針對零基礎Java學習的路線：如何從零學習Java，希望大家都能夠學有所成學有所長！
⑸ zookeeper+bbo+rocketmq集群是怎麼部署的，rocketmq、zookeeper都需要集群配置嗎大神能給個架構圖嗎
按要求簡單架構圖就這樣的，zookeeper 和 rocketmq 可集群也可不集群
⑹ rocketmq單個機器怎麼搭建集群在linux
linux伺服器集群平台的搭建比較簡單，有專門的均衡軟體，比如lvs，lvs是一個集群系統，由很多伺服器組成，可以根據需要，把它門分為三層，一層是前端機，用於均衡，相當於公平為系統分配工作，二層是伺服器群，比如web伺服器群，DNS，mail群等，這些就是接待員，把均衡器分配的工作進行處理，第三層是存儲設備，用於存儲數據，相當於檔案庫。
知道這些後，要搭建就非常容易，有現成的軟體，比如我有四台web伺服器，2台資料庫，1台前置機 ，安裝linux系統，安裝lvs軟體，比如
heartbeat-2.1.4-9.el5.i386.rpm
heartbeat-ldirectord-2.1.4-9.el5.i386.rpm
libnet-1.1.4-3.el5.i386.rpm
heartbeat-devel-2.1.4-9.el5.i386.rpm
heartbeat-pils-2.1.4-10.el5.i386.rpm
perl-MailTools-1.77-1.el5.noarch.rpm
heartbeat-gui-2.1.4-9.el5.i386.rpm
heartbeat-stonith-2.1.4-10.el5.i386.rpm
當然還需要配置，你可以自己網路有關lvs集群的詳細安裝說明。希望能幫助你。
⑺ rocketMQ如何設置消費線程數
能選擇的有三種：
1. ActiveMQ/ApolloMQ
優點：老牌的消息隊列，使用Java語言編寫。對JMS支持最好，採用多線程並發，資源消耗比較大。如果你的主語言是Java，可以重點考慮。
缺點：由於歷史悠久，歷史包袱較多，版本更新很緩慢。集群模式需要依賴Zookeeper實現。最新架構的產品被命名為Apollo，號稱下一代ActiveMQ，目前案例較少。
2. RocketMQ/Kafka
優點：專為海量消息傳遞打造，主張使用拉模式，天然的集群、HA、負載均衡支持。話說還是那句話，適合不適合看你有沒有那麼大的量。
缺點：所謂魚和熊掌不可兼得，放棄了一些消息中間件的靈活性，使用的場景較窄，需關注你的業務模式是否契合，否則山寨變相使用很別扭。除此之外，RocketMQ沒有.NET下的客戶端可用。RocketMQ身出名門，但使用者不多，生態較小，畢竟消息量能達到這種體量的公司不多，你也可以直接去購買阿里雲的消息服務。Kafka生態完善，其代碼是用Scala語言寫成，可靠性比RocketMQ低一些。
3. RabbitMQ
⑻ rocketmqbroker默認accesskey
本來這個錯誤是很簡單的錯誤，本意是mq上邊開啟了acl驗證機制，而客戶端沒有配置accessKey。
配置mq的broker和plain_acl兩個配置文件，客戶端加入acl相關代碼，主要是加入了AclRPCHook，在發送消息之前插入accessKey和簽名供mq進行校驗。之後用測試工程引用本地maven庫上安裝的rocket工具庫進行測試，結果之前能用的代碼在用了acl之後一直報錯：提示accessKey沒配置。