php中間件

⑴ 怎麼理解【前台php，中間件用java，底層用C/C++】

通常來說，做一個中小型網站或Web應用不會用多種服務端語言環境。
根據你所需要的網站需求決定要使用的技術架構。

首先PHP不是WEB前台技術（HTML+CSS+JavaScript才是，PHP與Web前端關系不大，這一點很多人都搞不清楚），PHP也是服務端的，說前台PHP個人感覺描述不當，你可以說表層PHP更准確點。PHP是解釋性語言，語言靈活、約束少、容錯高，即使代碼語法上寫錯了也未必影響整個網站的運行，適合實現低邏輯密度的業務處理。另外PHP的一些成熟框架也是支持插入中間件的。像博客、論壇、門戶網站等適合用PHP實現。

Java是一門比較健壯的語言環境，強類型、半編譯，可在運行時對自身代碼進行認知（反射），Java作為開源熱門，用Java編寫的實用工具如海洋般廣闊，所以利用Struts、Spring等成熟的JavaEE框架可以很方便地將這些工具作為中間層放置到Web應用當中。中間件通常是放置在原始服務端與客戶端之間的一個處理層，可能是個程序，也可能是一個伺服器（電腦），用於對原始數據進行進一步加工、篩選。Java十分適合製作業務邏輯比較復雜，對安全性、正確性與運行效率要求較高的網站或Web服務。像銀行系統、支付平台、在線聊天、網頁游戲等適合Java實現。

C/C++是目前大部分操作系統編寫時所用的語言，所以用C/C++可以很輕易地接觸到操作系統最底層的介面，C/C++很少用於網站或Web服務的開發。另外C/C++的編譯是平台相關的，同時也是平台最優化的，所以在復雜數據結構、演算法的處理能力上相較於其他語言有很大的優勢。像大型網游的伺服器可能由C/C++實現。

⑵ Laravel5.2默認會給路由增加Web中間件，怎麼禁用掉

app\Http\Providers\RouteServiceProvider.php 中 mapRoute 取消強制給加上的web中間件調用。自己在自己的路由中需要的時候增加 middleware=>web 即可

⑶ 使用node做中間件，實現express+php/java做分離式開發，模板渲染和路由問題

路由
通常HTTP URL的格式是這樣的：
http://host[:port][path]
http表示協議。
host表示主機。
port為埠，可選欄位，不提供時默認為80。
path指定請求資源的URI(Uniform Resource Identifier，統一資源定位符)，如果URL中沒有給出path，一般會默認成「/」（通常由瀏覽器或其它HTTP客戶端完成補充上）。
所謂路由，就是如何處理HTTP請求中的路徑部分。比如「http://xxx.com/users/profile」這個URL，路由將決定怎麼處理/users/profile這個路徑。
來回顧我們在Node.js開發入門——Express安裝與使用中提供的express版本的HelloWorld代碼：
var express = require('express');var app = express();app.get('/', function (req, res) { res.send('Hello World!');});app.listen(8000, function () { console.log('Hello World is listening at port 8000');});上面代碼里的app.get()調用，實際上就為我們的網站添加了一條路由，指定「/」這個路徑由get的第二個參數所代表的函數來處理。
express對象可以針對常見的HTTP方法指定路由，使用下面的方法：
app.METHOD(path, callback [, callback ...])METHOD可以是GET、POST等HTTP方法的小寫，例如app.get，app.post。path部分呢，既可以是字元串字面量，也可以是正則表達式。最簡單的例子，把前面代碼里的app.get()調用的一個參數』/』修改為』*』，含義就不一樣。改動之前，只有訪問「http://localhost:8000」或「http://localhost:8000/」這種形式的訪問才會返回「Hello World!」，而改之後呢，像「http://localhost:8000/xxx/yyyy.zz」這種訪問也會返回「Hello World!」。
使用express構建Web伺服器時，很重要的一部分工作就是決定怎麼響應針對某個路徑的請求，也即路由處理。
最直接的路由配置方法，就是調用app.get()、app.post()一條一條的配置，不過對於需要處理大量路由的網站來講，這會搞出人命來的。所以呢，我們實際開發中需要結合路由參數（query string、正則表達式、自定義的參數、post參數）來減小工作量提高可維護性。更詳細的信息，參考http://expressjs.com/guide/routing.html。
中間件
Express里有個中間件（middleware）的概念。所謂中間件，就是在收到請求後和發送響應之前這個階段執行的一些函數。
要在一條路由的處理鏈上插入中間件，可以使用express對象的use方法。該方法原型如下：
app.use([path,] function [, function...])當app.use沒有提供path參數時，路徑默認為「/」。當你為某個路徑安裝了中間件，則當以該路徑為基礎的路徑被訪問時，都會應用該中間件。比如你為「/abcd」設置了中間件，那麼「/abcd/xxx」被訪問時也會應用該中間件。
中間件函數的原型如下：
function (req, res, next)
第一個參數是Request對象req。第二個參數是Response對象res。第三個則是用來驅動中間件調用鏈的函數next，如果你想讓後面的中間件繼續處理請求，就需要調用next方法。
給某個路徑應用中間件函數的典型調用是這樣的：
app.use('/abcd', function (req, res, next) { console.log(req.baseUrl); next();})app.static中間件
Express提供了一個static中間件，可以用來處理網站里的靜態文件的GET請求，可以通過express.static訪問。
express.static的用法如下：
express.static(root, [options])
第一個參數root，是要處理的靜態資源的根目錄，可以是絕對路徑，也可以是相對路徑。第二個可選參數用來指定一些選項，比如maxAge、lastModified等，更多選項的介紹看這里：http://expressjs.com/guide/using-middleware.html#middleware.built-in。
一個典型的express.static應用如下：
var options = { dotfiles: 'ignore', etag: false, extensions: ['htm', 'html'], index: false, maxAge: '1d', redirect: false, setHeaders: function (res, path, stat) { res.set('x-timestamp', Date.now()); }}app.use(express.static('public', options));上面這段代碼將當前路徑下的public目錄作為靜態文件，並且為Cache-Control頭部的max-age選項為1天。還有其它一些屬性，請對照express.static的文檔來理解。
使用express創建的HelloExpress項目的app.js文件里有這樣一行代碼：
app.use(express.static(path.join(__dirname, 'public')));這行代碼將HelloExpress目錄下的public目錄作為靜態文件交給static中間件來處理，對應的HTTP URI為「/」。path是一個Node.js模塊，__dirname是Node.js的全局變數，指向當前運行的js腳本所在的目錄。path.join()則用來拼接目錄。
有了上面的代碼，你就可以在瀏覽器里訪問「http://localhost:3000/stylesheets/style.css」。我們做一點改動，把上面的代碼修改成下面這樣：
app.use('/static', express.static(path.join(__dirname, 'public')));上面的代碼呢，針對/static路徑使用static中間件處理public目錄。這時你再用瀏覽器訪問「http://localhost:3000/stylesheets/」就會看到一個404頁面，將地址換成「http://localhost:3000/static/stylesheets/style.css」就可以了。
Router
Express還提供了一個叫做Router的對象，行為很像中間件，你可以把Router直接傳遞給app.use，像使用中間件那樣使用Router。另外你還可以使用router來處理針對GET、POST等的路由，也可以用它來添加中間件，總之你可以將Router看作一個微縮版的app。
下面的代碼創建一個Router實例：
var router = express.Router([options]);
然後你就可以像使用app一樣使用router（代碼來自http://expressjs.com/4x/api.html#router）：
// invoked for any requests passed to this routerrouter.use(function(req, res, next) { // .. some logic here .. like any other middleware next();});// will handle any request that ends in /events// depends on where the router is "use()'d"router.get('/events', function(req, res, next) { // ..});定義了router後，也可以將其作為中間件傳遞給app.use：
app.use('/events', router);
上面這種用法，會針對URL中的「/events」路徑應用router，你在router對象上配置的各種路由策略和中間件，都會被在合適的時候應用。
路由模塊
express工具創建的應用，有一個routes目錄，下面保存了應用到網站的Router模塊，index.js和user.js。這兩個模塊基本一樣，我們研究一下index.js。
下面是index.js的內容：
var express = require('express');var router = express.Router();/* GET home page. */router.get('/', function(req, res, next) { res.render('index', { title: 'Express' });});mole.exports = router;index.js創建了一個Router實例，然後調用router.get為「/」路徑應用了路由函數。最後呢使用mole.exports將Router對象導出。
下面是app.js里引用到index.js的代碼：
var routes = require('./routes/index');...app.use('/', routes);第一處，require(『./routes/index』)將其作為模塊使用，這行代碼導入了index.js，並且將index.js導出的router對象保存在變數routes里以供後續使用。注意，上面代碼里的routes就是index.js里的router。
第二處代碼，把routes作為一個中間件，掛載到了「/」路徑上。
模塊
前面分析index.js時看到了mole.exports的用法。mole.exports用來導出一個Node.js模塊內的對象，調用者使用require載入模塊時，就會獲得導出的對象的實例。
我們的index.js導出了Router對象。app.js使用require(『./routes/index』)獲取了一個Router實例。
mole.exports還有一個輔助用法，即直接使用exports來導出。
exports.signup = function(req, res){ //some code}exports.login = function(req, res){ //some code}
上面的代碼（假定在users.js文件里）直接使用exports來導出。當使用exports來導出時，你設置給exports的屬性和方法，實際上都是mole.exports的。這個模塊最終導出的是mole.exports對象，你使用類似「exports.signup」這種形式設置的方法或屬性，調用方在require後都可以直接使用。
使用users模塊的代碼可能是這樣的：
var express = require('express');var app = express();...var users = require('./routes/users');app.post('/signup', users.signup);app.post('/login', users.login);...
1. 什麼是router路徑，什麼是middleware？
我們輸入www..com 來訪問網路的主頁，瀏覽器會自動轉換為 http://www..com:80/(省略一些參數)。 http://代表我們同伺服器連接使用的是http協議，www..com 代表的是伺服器的主機地址，會被我們的pc通過DNS解析為IP地址。80是默認的應用層埠。/ 即為我們訪問的伺服器(www..com)的路徑，伺服器要對我們訪問的這個路徑做出響應，採取一定的動作。我們可以把這一過程看做一個路由。
訪問的路徑『/』即為router的路徑，伺服器採取的動作即為middleware，即為一個個特殊的函數。
2. router路徑
www..com/test: 路徑為 /test
www..com/test?name=1&number=2: 路徑同樣為/test, ?後面會被伺服器理解傳給路徑的參數。
3. Middleware
復制代碼
An Express application is essentially a stack of middleware which are executed serially.(express應用其實就是由一系列順序執行的Middleware組成。)A middleware is a function with access to the request object (req), the response object (res), and the next middleware in line in the request-response cycle of an Express application. It is commonly denoted by a variable named next. Each middleware has the capacity to execute any code, make changes to the request and the reponse object, end the request-response cycle, and call the next middleware in the stack. Since middleware are execute serially, their order of inclusion is important.(中間件其實就是一個訪問express應用串入的req，res，nex參數的函數，這個函數可以訪問任何通過req，res傳入的資源。)If the current middleware is not ending the request-response cycle, it is important to call next() to pass on the control to the next middleware, else the request will be left hanging.(如果當前中間件沒有完成對網頁的res響應 ，還可以通過next把router 留給下一個middleware繼續執行)With an optional mount path, middleware can be loaded at the application level or at the router level. Also, a series of middleware functions can be loaded together, creating a sub-stack of middleware system at a mount point.
復制代碼
路由的產生是通過HTTP的各種方法(GET, POST)產生的，Middleware可以跟router路徑跟特定的HTTP方法綁定，也可以跟所有的方法綁定。
3.1 通過express應用的use（all），把Middleware同router路徑上的所有HTTP方法綁定：
1 app.use(function (req, res, next) {2 console.log('Time: %d', Date.now());3 next();4 })3.2 通過express應用的http.verb，把Middleware同router路徑上的特定的HTTP方法綁定：
復制代碼
1 app.get('/', function(req, res){2 res.send('hello world');3 });4 5 6 app.post('/', function(req, res){7 res.send('hello world');8 });復制代碼
4. Express的Router對象
當express實例的路由越來越多的時候，最好把路由分類獨立出去，express的實例(app) 能更好的處理其他邏輯流程。Express的Router對象是一個簡化的 app實例，只具有路由相關的功能，包括use, http verbs等等。最後這個Router再通過app的use掛載到app的相關路徑下。
復制代碼
1 var express = require('express'); 2 var app = express(); 3 var router = express.Router(); 4 5 // simple logger for this router's requests 6 // all requests to this router will first hit this middleware 7 router.use(function(req, res, next) { 8 console.log('%s %s %s', req.method, req.url, req.path); 9 next();10 });11 12 // this will only be invoked if the path ends in /bar13 router.use('/bar', function(req, res, next) {14 // ... maybe some additional /bar logging ...15 next();16 });17 18 // always invoked19 router.use(function(req, res, next) {20 res.send('Hello World');21 });22 23 app.use('/foo', router);24 25 app.listen(3000);復制代碼
router的路由必須通過app.use和app.verbs 掛載到app上才能被響應。所以上述代碼，只有在app捕捉到 /foo路徑上的路由時，才能router中定義的路由，雖然router中有針對 '/' 的路由，但是被app中的路由給覆蓋了。
附：app.verbs和app.use的路由路徑區別：
先看一段測試代碼：
var express = require('express');var app = express();var router = express.Router();app.get('/', function(req, res){ console.log('test1');});app.use('/', function(req, res){ console.log('test2');});router.get('/', function(req, res){ console.log('test3');});app.listen(4000);輸入url： localhost:4000
輸出結果：test1
輸入url： localhost:4000/hello
輸出結果：test2
結論：app.get掛載『/』的路由只響應跟'/'精確匹配的GET請求。 而app.use掛載的'/'的路由響應所有以'/' 為起始路由的路由，且不限制HTTP訪問的方法。以下說明：Mounting a middleware at a path will cause the middleware function to be executed whenever the base of the requested path matches the path.
1 app.use([path], [function...], function)2 Mount the middleware function(s) at the path. If path is not specified, it defaults to "/".3 4 Mounting a middleware at a path will cause the middleware function to be executed whenever the base of the requested path matches the path.

⑷ thinkphp6 的中間件會自動運行嗎為何沒有調用就自動運行了

你這樣相當於同時定義了應用中間件和控制器中間件,執行順序為
全局中間件->應用中間件->路由中間件->控制器中間件
這樣是會執行兩次的!!!
如果只想執行一次的話,幹掉其中之一就行.

⑸ php 如何連接mycat資料庫中間件嗎

肯定要先搭主從....mycat...通俗點說..就是一個分布式管理系統,是一個中間件,在應用於數據間負責協調統籌作用.具體資料庫的工作還是在mysql這邊來完成...而且mysql還必須要開啟讀寫分離模式

⑹ php 分表分庫中間件

用原生php來寫，封裝一個db類，封裝一個table類，通過工廠模式來創建某個庫某個表的對象，有了這個對象就可以操作分庫分表了；這個中間件可以有自己的命名空間。

⑺ 大型的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）。
一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。

⑻ Thinkphp6中間件引起驗證碼不顯示

驗證登錄,你得用前置,就是說,你得把你的if寫在 response的前面,你現在這是寫在後面.當然不會執行驗證登錄
望採納!

⑼ 文件上傳漏洞成因是什麼

如何利用漏洞對目標進行滲透測試，這些文件上傳漏洞產生的原因及防禦文件上傳漏洞的方法，文件解析漏洞，是指中間件（Apache、nginx、iis等）在解析文件時出現了漏洞，從而，黑客可以利用該漏洞實現非法文件的解析。
需要注意的是解析漏洞與上傳漏洞是兩碼事，文件解析漏洞是基於文件上傳之後而言的。
比如，Apache中間件，是c、c++混合寫成的，當Apache中間件出現了解析漏洞，即：c、c++編程出現了漏洞，無論我們php代碼層面如何的安全，都沒辦法抵擋黑客的攻擊，因為現在的漏洞已經與php代碼層無關了，已經是底層的安全問題了，文件解析漏洞就是因為Apache中間件c、c++編程出現了漏洞，導致黑客可以利用該漏洞解析非法文件。
所以，底層安全比任何安全都要重要，至少我們從現在起，要開始重視底層安全了。

⑽ ASP微信支付如何寫PHP中間件

ASP可以不用中間件的，需要到伺服器導入個證書。
另外你可以採用聚合支付方式，也帶微信支付功能。