php高可用

1. 如何實現php+session+memcached高可用集群

在這個互聯網高度發達的時代，許多應用的用戶動輒成百上千萬，甚至上億。為了支持海量用戶的訪問，應用伺服器集群這種水平擴展的方式是最常用的。這種情形下，就會涉及到許多單機環境下完全不需要考慮的問題，這其中session的創建、共享和存儲是最常見之一。
在單機環境中，Session的創建和存儲都是由同一個應用伺服器實例來完成，而存儲也僅是內存中，最多會在正常的停止伺服器的時候，把當前活動的Session鈍化到本地，再次啟動時重新載入。
而多個實例之間，Session數據是完全隔離的。而為了實現Session的高可用，多實例間數據共享是必然的，下面我們以Redis 的SessionManager實現多Tomcat實例Session共享的配置為例，我們來梳理下一般session共享的流程：
添加具體要使用的manager的Jar文件及其依賴
redis session manager依賴jedis, commons-pool, commons-pool2
對應版本的redis session manager的jar文件
在TOMCAT_HOME/conf/context.xml中增加如下配置
<Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" />
<Manager className="com.radiadesign.catalina.session.RedisSessionManager"
host="localhost"
port="6379" database="0"
maxInactiveInterval="30" />
其中host和port等替換為對應的配置信息
啟動多個Tomcat實例，以自帶的examples應用為例進行驗證
訪問examples應用的servlets/servlet/SessionExample，
在頁面中添加數據到session中，並查看頁面上對應的session信息
訪問另一個實例上相同應用的頁面，查看session信息，兩者應該是一致的
使用redis-cli查看redis中存儲的對應數據，相應的sessionId對應的數據已經保存了下來
以上是一個基本的配置過程，而在這些配置與驗證的步驟中，第二步是核心邏輯實現。 前面的文章，曾介紹過Tomcat的Valve，在請求處理時，Pipeline中的各個Valve的invoke方法會依次執行。Tomcat的AccessLogValve介紹
此處的session處理，就是以一個自定義Valve的形式進行的。關於Session的文章，前面也寫過幾篇，會附在結尾處。
以下是RedisSessionhandlerValve的invoke方法，我們看，主要是在Valve執行後進行Session的存儲或移除。
public void invoke(Request request, Response response) {
try {
getNext().invoke(request, response);
} finally {
final Session session = request.getSessionInternal(false);
storeOrRemoveSession(session);
manager.afterRequest();
}
}
而session的保存和移除又是通過manager執行的。 manager.save(session); manager.remove(session);
這里，manager就是前面定義的RedisSessionManager。默認單實例情況下，我們使用的都是StandardManager，對比一下兩者，標準的Manager對於session的創建和刪除，都會調到其父類ManagerBase中相應的方法，
public void add(Session session) {
sessions.put(session.getIdInternal(), session);
int size = getActiveSessions();
if( size > maxActive ) {
synchronized(maxActiveUpdateLock) {
if( size > maxActive ) {
maxActive = size;
}
}
}
}
public void remove(Session session, boolean update) {
if (session.getIdInternal() != null) {
sessions.remove(session.getIdInternal());
}
}
我們來看，由於其只保存在內存的Map中protected Map<String, Session> sessions = new
ConcurrentHashMap<>()，每個Tomcat實例都對於不同的map，多個實例間無法共享數據。
對應到RedisSessionManager對於session的處理，都是直接操作redis，基本代碼是下面這個樣：
public void save(Session session) throws IOException {
Jedis jedis = null;
Boolean error = true;
try {
RedisSession redisSession = (RedisSession) session;
Boolean sessionIsDirty = redisSession.isDirty();
redisSession.resetDirtyTracking();
byte[] binaryId = redisSession.getId().getBytes();
jedis = acquireConnection();
if (sessionIsDirty || currentSessionIsPersisted.get() != true) {
jedis.set(binaryId, serializer.serializeFrom(redisSession));
}
currentSessionIsPersisted.set(true);
jedis.expire(binaryId, getMaxInactiveInterval());
} }
移除時的操作是這樣的
public void remove(Session session, boolean update) {
Jedis jedis = null;
Boolean error = true;
log.trace("Removing session ID : " + session.getId());
try {
jedis = acquireConnection();
jedis.del(session.getId());
error = false;
} finally {
if (jedis != null) {
returnConnection(jedis, error);
}
}
}
而此時，多個Tomcat實例都讀取相同的Redis，session數據是共享的，其它實例的初始請求過來時，由於會執行findSession的操作，此時會從Redis中載入session，
public Session findSession(String id) throws IOException {
RedisSession session;
if (id == null) {
session = null;
currentSessionIsPersisted.set(false);
} else if (id.equals(currentSessionId.get())) {
session = currentSession.get();
} else {
session = loadSessionFromRedis(id); // 看這里，會從redis中load
if (session != null) {
currentSessionIsPersisted.set(true);
}
}
currentSession.set(session);
currentSessionId.set(id);
return session;
}
從而可以保證在一個實例被切換後，另外的實例可以繼續響應同一個session的請求。
以上即為Redis實現session共享高可用的一些關鍵內容。有興趣的朋友可以看下通過Memcached實現高可用，也是這個原理。順著這個思路，如果你有將Session存儲在其它地方的需求時，完全可以寫一個出來，自己動手，豐衣足食。
總結一下，我們是通過自定義的Valve來實現請求後session的攔截，同時，使用自定義的SessionManager,來滿足不同的session創建與存儲的需求。而至於是存儲在Redis/Memcached中，還是存儲在DB中，只是位置的區別。原理，是一致的。

2. Nginx 與 PHP 合並部署與分開部署 哪種性能更好一些

當然是分開部署了，很簡單的理解，同樣的一項業務，分散到不同的營業部的話，處理業務的速度會相應加快，如果把人員集中到一個營業部，你會發現，光排隊處理一項就把你搞死。

3. 架構高可用高並發系統的設計原則

通過學習《億級流量網站架構核心技術》及《linux就該這么學》學習筆記及自己的感悟：架構設計之高可用高並發系統設計原則，架構設計包括墨菲定律、康威定律和二八定律三大定律，而系統設計包括高並發原則、高可用和業務設計原則等。
架構設計三大定律
墨菲定律 – 任何事沒有表面看起來那麼簡單 – 所有的事都會比預計的時間長 – 可能出錯的事情總會出錯 – 擔心某種事情發生，那麼它就更有可能發生
康威定律 – 系統架構師公司組織架構的反映 – 按照業務閉環進行系統拆分/組織架構劃分，實現閉環、高內聚、低耦合，減少溝通成本 – 如果溝通出現問題，應該考慮進行系統和組織架構的調整 – 適合時機進行系統拆分，不要一開始就吧系統、服務拆分拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高 – 微服務架構的理論基礎 – 康威定律https://yq.aliyun.com/articles/8611– 每個架構師都應該研究下康威定律http://36kr.com/p/5042735.html
二八定律 – 80%的結果取決於20%的原因
系統設計遵循的原則
1.高並發原則
無狀態
無狀態應用，便於水平擴展
有狀態配置可通過配置中心實現無狀態
實踐: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分
系統維度：按照系統功能、業務拆分，如購物車，結算，訂單等
功能維度：對系統功能在做細粒度拆分
讀寫維度：根據讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表
AOP維度： 根據訪問特徵，按照AOP進行拆分，比如商品詳情頁可分為CDN、頁面渲染系統，CDN就是一個AOP系統
模塊維度：對整體代碼結構劃分Web、Service、DAO
服務化
服務化演進: 進程內服務-單機遠程服務-集群手動注冊服務-自動注冊和發現服務-服務的分組、隔離、路由-服務治理
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等
實踐：利用Nginx、HaProxy、LVS等實現負載均衡，ZooKeeper、Consul等實現自動注冊和發現服
消息隊列
目的: 服務解耦(一對多消費)、非同步處理、流量削峰緩沖等
大流量緩沖： 犧牲強一致性，保證最終一致性(案例：庫存扣減，現在Redis中做扣減，記錄扣減日誌，通過後台進程將扣減日誌應用到DB)
數據校對: 解決非同步消息機制下消息丟失問題
數據異構
數據異構: 通過消息隊列機制接收數據變更，原子化存儲
數據閉環: 屏蔽多從數據來源，將數據異構存儲，形成閉環
緩存銀彈
用戶層:
DNS緩存
瀏覽器DNS緩存
操作系統DNS緩存
本地DNS服務商緩存
DNS伺服器緩存
客戶端緩存
瀏覽器緩存(Expires、Cache-Control、Last-Modified、Etag)
App客戶緩存(js/css/image…)
代理層：
CDN緩存(一般基於ATS、Varnish、Nginx、Squid等構建,邊緣節點-二級節點-中心節點-源站)
接入層：
Opcache： 緩存PHP的Opcodes
Proxy_cache： 代理緩存,可以存儲到/dev/shm或者SSD
FastCGI Cache
Nginx+Lua+Redis: 業務數據緩存
Nginx為例：
PHP為例：
應用層：
頁面靜態化
業務數據緩存(Redis/Memcached/本地文件等)
消息隊列
數據層：
Nosql： Redis、Memcache、SSDB等
MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系統層：
CPU : L1/L2/L3 Cache/NUMA
內存
磁碟：磁碟本身緩存、dirtyratio/dirtybackground_ratio、陣列卡本身緩存
並發化
2.高可用原則
降級
降級開關集中化管理：將開關配置信息推送到各個應用
可降級的多級讀服務：如服務調用降級為只讀本地緩存
開關前置化：如Nginx+lua(OpenResty)配置降級策略，引流流量；可基於此做灰度策略
業務降級：高並發下，保證核心功能，次要功能可由同步改為非同步策略或屏蔽功能
限流
目的: 防止惡意請求攻擊或超出系統峰值
實踐：
惡意請求流量只訪問到Cache
穿透後端應用的流量使用Nginx的limit處理
惡意IP使用Nginx Deny策略或者iptables拒絕
切流量
目的：屏蔽故障機器
實踐:
DNS: 更改域名解析入口，如DNSPOD可以添加備用IP，正常IP故障時，會自主切換到備用地址;生效實踐較慢
HttpDNS: 為了繞過運營商LocalDNS實現的精準流量調度
LVS/HaProxy/Nginx: 摘除故障節點
可回滾
發布版本失敗時可隨時快速回退到上一個穩定版本
3.業務設計原則
防重設計
冪等設計
流程定義
狀態與狀態機
後台系統操作可反饋
後台系統審批化
文檔注釋
備份
4.總結
先行規劃和設計時有必要的，要對現有問題有方案，對未來有預案;欠下的技術債，遲早都是要還的。
本文作者為網易高級運維工程師

4. 開發一個網站，後端用go語言，前端用PHP、Ruby還是python比較好

首先我告訴你，你所描述的全都是後端開發語言，並不是前端

GO、PHP、Ruby、Python全都是後端、且注重的領域不一樣

GO專注於大型高並發、高性能項目，R、PY都是面向對象的動態槐漏嫌語言

接下來可以談一談目前還可以的PHP語言，開發網站首選，且過去幾年PHP中的非同步框架也開始興起，比如Swoole、Swoft和ReactPHP等等，都是用PHP或其他語言編寫的框架和伺服器

可以讓PHP程序員搜神不需要學習另外一門語言、也可以用PHP實現高並發、高可鉛手用、微服務架構，即時通信等，關鍵還省錢解約成本，能夠讓用戶運行真正的協程非同步。

PHP7+Swoole性能僅次於C、Java和GO、讓PHP程序員既可以動態開發又可以實現高並發！Swoole協程編程、並發編程、Swoft微服務、等技術都是成為一個中高級PHPer，架構師的必經之路，為了幫助大家進階中高級漲薪、

我為大家准備了一套精品福利！還可加入大牛學習圈子，分享tp,laravel，Swoole，Swoft微服務等教程，各種大牛都是3-8年PHP開發者，每天還有12年的架構師做講解，助你進階中高級PHP程序員，增值漲薪！需要可關注本頭條號，並且發送私信：PHP

PHPer想掌握Swoole協程編程、並發編程、進階PHP中高級，架構師的可以來學習

5. 大型的PHP應用，通常使用什麼應用做消息隊列

一、消息隊列概述
消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，非同步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。
二、消息隊列應用場景
以下介紹消息隊列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和消息通訊四個場景。
2.1非同步處理
場景說明：用戶注冊後，需要發注冊郵件和注冊簡訊。傳統的做法有兩種1.串列的方式；2.並行方式。
（1）串列方式：將注冊信息寫入資料庫成功後，發送注冊郵件，再發送注冊簡訊。以上三個任務全部完成後，返回給客戶端。（架構KKQ：466097527，歡迎加入）
（2）並行方式：將注冊信息寫入資料庫成功後，發送注冊郵件的同時，發送注冊簡訊。以上三個任務完成後，返回給客戶端。與串列的差別是，並行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鍾，不考慮網路等其他開銷，則串列方式的時間是150毫秒，並行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。
小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？
引入消息隊列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：
按照以上約定，用戶的響應時間相當於是注冊信息寫入資料庫的時間，也就是50毫秒。注冊郵件，發送簡訊寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串列提高了3倍，比並行提高了兩倍。
2.2應用解耦
場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的介面。如下圖：
傳統模式的缺點：
1） 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；
2） 訂單系統與庫存系統耦合；
如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：
訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。
庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。
假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。
2.3流量削鋒
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。
可以控制活動的人數；
可以緩解短時間內高流量壓垮應用；
用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；
秒殺業務根據消息隊列中的請求信息，再做後續處理。
2.4日誌處理
日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下：
日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列；
Kafka消息隊列，負責日誌數據的接收，存儲和轉發；
日誌處理應用：訂閱並消費kafka隊列中的日誌數據；
以下是新浪kafka日誌處理應用案例：
(1)Kafka：接收用戶日誌的消息隊列。
(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch。
(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。
(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。
2.5消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
點對點通訊：
客戶端A和客戶端B使用同一隊列，進行消息通訊。
聊天室通訊：
客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。
以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。模型為示意圖，供參考。
三、消息中間件示例
3.1電商系統
消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）
（2）擴展流程（發簡訊，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。
（3）消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。比如主數據寫入資料庫，擴展應用根據消息隊列，並結合資料庫方式實現基於消息隊列的後續處理。
3.2日誌收集系統
分為Zookeeper注冊中心，日誌收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。
Zookeeper注冊中心，提出負載均衡和地址查找服務；
日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列；
四、JMS消息服務
講消息隊列就不得不提JMS 。JMS（Java Message Service,Java消息服務）API是一個消息服務的標准/規范，允許應用程序組件基於JavaEE平台創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及非同步性。
在EJB架構中，有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。
4.1消息模型
在JMS標准中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。
4.1.1 P2P模式
P2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到他們被消費或超時。
P2P的特點
每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)
發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之後，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列
接收者在成功接收消息之後需向隊列應答成功
如果希望發送的每個消息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）
4.1.2 Pub/sub模式
包含三個角色主題（Topic），發布者（Publisher），訂閱者（Subscriber） 。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
Pub/Sub的特點
每個消息可以有多個消費者
發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發布者的消息。
為了消費消息，訂閱者必須保持運行的狀態。
為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。
如果希望發送的消息可以不被做任何處理、或者只被一個消息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。
4.2消息消費
在JMS中，消息的產生和消費都是非同步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。
（1）同步
訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時之前）將一直阻塞；
（2）非同步
訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之後，系統自動調用監聽器的onMessage方法。
JNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查找和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪問發送目標或消息來源的作用。（架構KKQ：466097527，歡迎加入）
4.3JMS編程模型
(1) ConnectionFactory
創建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查找ConnectionFactory對象。
(2) Destination
Destination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。對於消息生產者來說，它的Destination是某個隊列（Queue）或某個主題（Topic）;對於消息消費者來說，它的Destination也是某個隊列或主題（即消息來源）。
所以，Destination實際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。
(3) Connection
Connection表示在客戶端和JMS系統之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。
(4) Session
Session是操作消息的介面。可以通過session創建生產者、消費者、消息等。Session提供了事務的功能。當需要使用session發送/接收多個消息時，可以將這些發送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。
(5) 消息的生產者
消息生產者由Session創建，並用於將消息發送到Destination。同樣，消息生產者分兩種類型：QueueSender和TopicPublisher。可以調用消息生產者的方法（send或publish方法）發送消息。
(6) 消息消費者
消息消費者由Session創建，用於接收被發送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創建。當然，也可以session的creatDurableSubscriber方法來創建持久化的訂閱者。
(7) MessageListener
消息監聽器。如果注冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。
深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，消息中間件也是大型分布式系統必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學習，實踐，總結，領會。
五、常用消息隊列
一般商用的容器，比如WebLogic，JBoss，都支持JMS標准，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。
5.1 ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息匯流排。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，盡管JMS規范出台已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
ActiveMQ特性如下：
⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4規范 （持久化，XA消息，事務)
⒊ 對spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支持Spring2.0的特性
⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業伺服器上
⒌ 支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通過JDBC和journal提供高速的消息持久化
⒎ 從設計上保證了高性能的集群，客戶端-伺服器，點對點
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 可以很容易得調用內嵌JMS provider，進行測試
5.2 RabbitMQ
RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標准實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
幾個重要概念：
Broker：簡單來說就是消息隊列伺服器實體。
Exchange：消息交換機，它指定消息按什麼規則，路由到哪個隊列。
Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。
Binding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。
Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。
vhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的許可權分離。
procer：消息生產者，就是投遞消息的程序。
consumer：消息消費者，就是接受消息的程序。
channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。
消息隊列的使用過程，如下：
（1）客戶端連接到消息隊列伺服器，打開一個channel。
（2）客戶端聲明一個exchange，並設置相關屬性。
（3）客戶端聲明一個queue，並設置相關屬性。
（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。
（5）客戶端投遞消息到exchange。
exchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。
5.3 ZeroMQ
號稱史上最快的消息隊列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網路編程更為簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。
引用官方的說法： 「ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成為標准網路協議棧的一部分，之後進入Linux內核」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網路應用程序極為簡單和有趣。」
特點是：
高性能，非持久化；
跨平台：支持Linux、Windows、OS X等。
多語言支持； C、C++、Java、.NET、Python等30多種開發語言。
可單獨部署或集成到應用中使用；
可作為Socket通信庫使用。
與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、進程通訊和線程通訊抽象為統一的API介面。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。
ZeroMQ高性能設計要點：
1、無鎖的隊列模型
對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列演算法CAS；在pipe兩端注冊有非同步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。
2、批量處理的演算法
對於傳統的消息處理，每個消息在發送和接收的時候，都需要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，可以批量的接收和發送消息。
3、多核下的線程綁定，無須CPU切換
區別於傳統的多線程並發模式，信號量或者臨界區， zeroMQ充分利用多核的優勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。
5.4 Kafka
Kafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。
Kafka是一種高吞吐量的分布式發布訂閱消息系統，有如下特性：
通過O(1)的磁碟數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。（文件追加的方式寫入數據，過期的數據定期刪除）
高吞吐量：即使是非常普通的硬體Kafka也可以支持每秒數百萬的消息。
支持通過Kafka伺服器和消費機集群來分區消息。
支持Hadoop並行數據載入。
Kafka相關概念
Broker
Kafka集群包含一個或多個伺服器，這種伺服器被稱為broker[5]
Topic
每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）
Partition
Parition是物理上的概念，每個Topic包含一個或多個Partition.
Procer
負責發布消息到Kafka broker
Consumer
消息消費者，向Kafka broker讀取消息的客戶端。
Consumer Group
每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於默認的group）。
一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。

6. PHP中高級面試題 – 第三天

一、簡述一下MongoDB的應用場景

mongodb 支持副本集、索引、自動分片，可以保證較高的性能和可用性。

更高的寫入負載

默認情況下，MongoDB 更側重高數據寫入性能，而非事務安全，MongoDB 很適合業務系統中有大量 「低價值」 數據的場景。但是應當避免在高事務安全性的系統中使用 MongoDB，除非能從架構設計上保證事務安全。

高可用性

MongoDB 的復副集 (Master-Slave) 配置非常簡潔方便，此外，MongoDB 可以快速響應的處理單節點故障，自動、安全地完成故障轉移。這些特性使得 MongoDB 能在一個相對不穩定（如雲主機）的環境中，保持高可用性。

數據量很大或者未來會變得很大

依賴資料庫 (MySQL) 自身的特性，完成數據的擴展是較困難的事，在 MySQL 中，當一個單達表到 5-10GB 時會出現明顯的性能降級，此時需要通過數據的水平和垂直拆分、庫的拆分完成擴展，使用 MySQL 通常需要藉助驅動層或代理層完成這類需求。而 MongoDB 內建了多種數據分片的特性，可以很好地適應大數據量的需求。

基於位置的數據查詢

MongoDB 支持二維空間索引，因此可以快速及精確地從指定位置獲取數據。

表結構不明確

在一些傳統 RDBMS 中，增加一個欄位會鎖住整個資料庫 / 表，或者在執行一個重負載的請求時會明顯造成其它請求的性能降級。通常發生在數據表大於 1G 的時候（當大於 1TB 時更甚）。 因 MongoDB 是文檔型資料庫，為非結構貨的文檔增加一個新欄位是很快速的操作，並且不會影響到已有數據。另外一個好處當業務數據發生變化時，是將不再需要由 DBA 修改表結構。

二、資料庫設計經驗，為什麼進行分表？分庫？一般多少數據量開始分表？分庫？分庫分表的目的？

1、為什麼要分表

當一張表的數據達到幾百萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。日常開發中我們經常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致資料庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯合查詢的情況，性能會更加糟糕。

分表和表分區的目的就是減少資料庫的負擔，提高資料庫的效率，通常點來講就是提高表的增刪改查效率。資料庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（CPU、磁碟、內存、IO 等）是有限的，最終資料庫所能承載的數據量、數據處理能力都將遭遇瓶頸。

2、分表的方案

做 mysql 集群，有人會問 mysql 集群，根分表有什麼關系嗎？雖然它不是實際意義上的分表，但是它啟到了分表的作用，做集群的意義是什麼呢？為一個資料庫減輕負擔，說白了就是減少 sql 排隊隊列中的 sql 的數量，舉個例子：有 10 個 sql 請求，如果放在一個資料庫伺服器的排隊隊列中，他要等很長時間，如果把這 10 個 sql 請求，分配到 5 個資料庫伺服器的排隊隊列中，一個資料庫伺服器的隊列中只有 2 個，這樣等待時間是不是大大的縮短了呢？

linux mysql proxy 的安裝，配置，以及讀寫分離

mysql replication 互為主從的安裝及配置，以及數據同步

優點：擴展性好，沒有多個分表後的復雜操作（php 代碼）

缺點：單個表的數據量還是沒有變，一次操作所花的時間還是那麼多，硬體開銷大。

三、簡述一下資料庫主從復制，讀寫分離

* 什麼是主從復制
主從復制，是用來建立一個和主資料庫完全一樣的資料庫環境，稱為從資料庫；

* 主從復制的原理：
1.資料庫有個bin-log二進制文件，記錄了所有的sql語句。
2.只需要把主資料庫的bin-log文件中的sql語句復制。
3.讓其從數據的relay-log重做日誌文件中再執行一次這些sql語句即可。

* 主從復制的作用
1.做數據的熱備份，作為後備資料庫，主資料庫伺服器故障後，可切換到從資料庫繼續工作，避免數據丟失。
2.架構的擴展。業務量越來越大，I/O訪問頻率過高，單機無法滿足，此時做多庫的存儲，降低磁碟I/O訪問頻率，提高單機的I/O性能
3.主從復制是讀寫分離的基礎，使資料庫能製成更大 的並發。例如子報表中，由於部署報表的sql語句十分慢，導致鎖表，影響前台的服務。如果前台服務使用master，報表使用slave，那麼報表sql將不會造成前台所，保證了前台的訪問速度。

* 主從復制的幾種方式：
1.同步復制：所謂的同步復制，意思是master的變化，必須等待slave-1,slave-2,…,slave-n完成後才能返回。
2.非同步復制：如同AJAX請求一樣。master只需要完成自己的資料庫操作即可。至於slaves是否收到二進制日誌，是否完成操作，不用關心。MYSQL的默認設置。
3.半同步復制：master只保證slaves中的一個操作成功，就返回，其他slave不管。
這個功能，是由google為MYSQL引入的。

* 關於讀寫分離
在完成主從復制時，由於slave是需要同步master的。所以對於insert/delete/update這些更新資料庫的操作，應該在master中完成。而select的查詢操作，則落下到slave中。

7. php和mysql查詢效率如何優化

那就用sphinx 技術，目前這個是最好的，沒有之一。
下面是我網路弄過來的，怎麼使用還得你自己看白皮書了。

Sphinx的主要特性包括：
高速索引 (在新款CPU上,近10 MB/秒);
高速搜索 (2-4G的文本量中平均查詢速度不到0.1秒);
高可用性 (單CPU上最大可支持100 GB的文本,100M文檔);
提供良好的相關性排名
支持分布式搜索;
提供文檔摘要生成;
提供從MySQL內部的插件式存儲引擎上搜索
支持布爾,短語, 和近義詞查詢;
支持每個文檔多個全文檢索域(默認最大32個);
支持每個文檔多屬性;
支持斷詞;
支持單位元組編碼與UTF-8編碼。[1]