整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
言碎語
今天來做個有趣的東西，就是實時將系統(tǒng)日志輸出的前端web頁面，因為是實時輸出，所有第一時間就想到了使用webSocket,而且在spring boot中，使用websocket超級方便，閱讀本文，你會接觸到以下關(guān)鍵詞相關(guān)技術(shù)，WebSocket（stopmp服務(wù)端），stomp協(xié)議，sockjs.min.js，stomp.min.js（stomp客戶端），本文使用到的其實就是使用spring boot自帶的webSocket模塊提供stomp的服務(wù)端，前端使用stomp.min.js做stomp的客戶端，使用sockjs來鏈接，前端訂閱后端日志端點的消息，后端實時推送，達到日志實時輸出到web頁面的目的，效果如下圖
首先了解下stomp？
STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，簡單(流)文本定向消息協(xié)議，它提供了一個可互操作的連接格式，允許STOMP客戶端與任意STOMP消息代理（Broker）進行交互。STOMP協(xié)議由于設(shè)計簡單，易于開發(fā)客戶端，因此在多種語言和多種平臺上得到廣泛地應(yīng)用。
STOMP協(xié)議的前身是TTMP協(xié)議（一個簡單的基于文本的協(xié)議），專為消息中間件設(shè)計。
STOMP是一個非常簡單和容易實現(xiàn)的協(xié)議，其設(shè)計靈感源自于HTTP的簡單性。盡管STOMP協(xié)議在服務(wù)器端的實現(xiàn)可能有一定的難度，但客戶端的實現(xiàn)卻很容易。例如，可以使用Telnet登錄到任何的STOMP代理，并與STOMP代理進行交互。
下面是具體的步驟，主要是日志信息的獲取和日志信息的推送，不多說，上代碼
一.引入spring boot websocket依賴
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> </dependency>
二.新增日志消息實體
/**
* Created by kl on 2017/10/9.
* Content :日志消息實體，注意，這里為了減少篇幅，省略了get,set代碼
*/
public class LoggerMessage{
private String body;
private String timestamp;
private String threadName;
private String className;
private String level;
public LoggerMessage(String body, String timestamp, String threadName, String className, String level) {
this.body=body;
this.timestamp=timestamp;
this.threadName=threadName;
this.className=className;
this.level=level;
}
public LoggerMessage() {
}
}三. 創(chuàng)建一個阻塞隊列，作為日志系統(tǒng)輸出的日志的一個臨時載體
public class LoggerQueue {
//隊列大小
public static final int QUEUE_MAX_SIZE=10000;
private static LoggerQueue alarmMessageQueue=new LoggerQueue();
//阻塞隊列
private BlockingQueueblockingQueue=new LinkedBlockingQueue<>(QUEUE_MAX_SIZE);
private LoggerQueue() {
}
public static LoggerQueue getInstance() {
return alarmMessageQueue;
}
/**
* 消息入隊
* @param log
* @return
*/
public boolean push(LoggerMessage log) {
return this.blockingQueue.add(log);//隊列滿了就拋出異常，不阻塞
}
/**
* 消息出隊
* @return
*/
public LoggerMessage poll() {
LoggerMessage result=null;
try {
result=this.blockingQueue.take();
} catch (InterruptedException e) {
e.printStackTrace();
}
return result;
}
}四.獲取logback的日志，塞入日志隊列中
1.定義Logfilter攔截輸出日志
public class LogFilter extends Filter{
@Override
public FilterReply decide(ILoggingEvent event) {
LoggerMessage loggerMessage=new LoggerMessage(
event.getMessage()
, DateFormat.getDateTimeInstance().format(new Date(event.getTimeStamp())),
event.getThreadName(),
event.getLoggerName(),
event.getLevel().levelStr
);
LoggerQueue.getInstance().push(loggerMessage);
return FilterReply.ACCEPT;
}
}2.配置logback.xml,添加我們自定義的filter
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true">
<include resource="org/springframework/boot/logging/logback/defaults.xml" />
<property name="LOG_FILE"
value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}/}spring.log}" />
<include resource="org/springframework/boot/logging/logback/file-appender.xml" />
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>${CONSOLE_LOG_PATTERN}</pattern>
<charset>utf8</charset>
</encoder>
<filter class="com.example.websocket.LogFilter"></filter>
</appender>
<root level="INFO">
<appender-ref ref="FILE" />
<appender-ref ref="CONSOLE" />
</root>
</configuration>五.配置WebSocket消息代理端點，即stomp服務(wù)端
@Configuration
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer{
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/websocket")
.setAllowedOrigins("http://localhost:8976")
.withSockJS();
}
}注意：為了連接安全，setAllowedOrigins設(shè)置的允許連接的源地址，如果在非這個配置的地址下發(fā)起連接會報403，進一步還可以使用addInterceptors設(shè)置攔截器，來做相關(guān)的鑒權(quán)操作
六.啟動類，開啟webSocket消息代理功能，并推送日志信息
@SpringBootApplication
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebsocketApplication {
private Logger logger=LoggerFactory.getLogger(WebsocketApplication.class);
public static void main(String[] args) {
SpringApplication.run(WebsocketApplication.class, args);
}
@Autowired
private SimpMessagingTemplate messagingTemplate;
int info=1;
@Scheduled(fixedRate=1000)
public void outputLogger(){
logger.info("測試日志輸出"+info++);
}
/**
* 推送日志到/topic/pullLogger
*/
@PostConstruct
public void pushLogger(){
ExecutorService executorService=Executors.newFixedThreadPool(2);
Runnable runnable=new Runnable() {
@Override
public void run() {
while (true) {
try {
LoggerMessage log=LoggerQueue.getInstance().poll();
if(log!=null){
if(messagingTemplate!=null)
messagingTemplate.convertAndSend("/topic/pullLogger",log);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
};
executorService.submit(runnable);
executorService.submit(runnable);
}
}七.html頁面，連接stomp服務(wù)端，訂閱/topic/pullLogger的消息，展示日志信息
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>WebSocket Logger</title>
<script src="https://cdn.bootcss.com/jquery/2.1.4/jquery.js"></script>
<script src="https://cdn.bootcss.com/sockjs-client/1.1.4/sockjs.min.js"></script>
<script src="https://cdn.bootcss.com/stomp.js/2.3.3/stomp.min.js"></script>
</head>
<body>
<button onclick="openSocket()">開啟日志</button><button onclick="closeSocket()">關(guān)閉日志</button>
<div id="log-container" style="height: 450px; overflow-y: scroll; background: #333; color: #aaa; padding: 10px;">
<div></div>
</div>
</body>
<script>
var stompClient=null;
$(document).ready(function() {openSocket();});
function openSocket() {
if(stompClient==null){
var socket=new SockJS('http://localhost:8084/websocket?token=kl');
stompClient=Stomp.over(socket);
stompClient.connect({token:"kl"}, function(frame) {
stompClient.subscribe('/topic/pullLogger', function(event) {
var content=JSON.parse(event.body);
$("#log-container div").append(content.timestamp +" "+ content.level+" --- ["+ content.threadName+"] "+ content.className+" :"+content.body).append("<br/>");
$("#log-container").scrollTop($("#log-container div").height() - $("#log-container").height());
},{
token:"kltoen"
});
});
}
}
function closeSocket() {
if (stompClient !=null) {
stompClient.disconnect();
stompClient=null;
}
}
</script>
</body>
</html>相關(guān)技術(shù)官網(wǎng)參考地址：
stomp.js客戶端：http://jmesnil.net/stomp-websocket/doc/
scok.js客戶端：https://github.com/sockjs/sockjs-client
spring webSocket：https://docs.spring.io/spring/docs/
源：前端工匠 作者：浪里行舟君
前言
HTTP/2 相比于 HTTP/1.1，可以說是大幅度提高了網(wǎng)頁的性能，只需要升級到該協(xié)議就可以減少很多之前需要做的性能優(yōu)化工作，當(dāng)然兼容問題以及如何優(yōu)雅降級應(yīng)該是國內(nèi)還不普遍使用的原因之一。
雖然 HTTP/2 提高了網(wǎng)頁的性能，但是并不代表它已經(jīng)是完美的了，HTTP/3 就是為了解決 HTTP/2 所存在的一些問題而被推出來的。
一、HTTP/1.1發(fā)明以來發(fā)生了哪些變化？
如果仔細(xì)觀察打開那些最流行的網(wǎng)站首頁所需要下載的資源的話，會發(fā)現(xiàn)一個非常明顯的趨勢。近年來加載網(wǎng)站首頁需要的下載的數(shù)據(jù)量在逐漸增加，并已經(jīng)超過了2100K。但在這里我們更應(yīng)該關(guān)心的是：平均每個頁面為了完成顯示與渲染所需要下載的資源數(shù)已經(jīng)超過了100個。
正如下圖所示，從2011年以來,傳輸數(shù)據(jù)大小與平均請求資源數(shù)量不斷持續(xù)增長，并沒有減緩的跡象。該圖表中綠色直線展示了傳輸數(shù)據(jù)大小的增長，紅色直線展示了平均請求資源數(shù)量的增長。
HTTP/1.1自從1997年發(fā)布以來，我們已經(jīng)使用HTTP/1.x 相當(dāng)長一段時間了，但是隨著近十年互聯(lián)網(wǎng)的爆炸式發(fā)展，從當(dāng)初網(wǎng)頁內(nèi)容以文本為主,到現(xiàn)在以富媒體（如圖片、聲音、視頻）為主,而且對頁面內(nèi)容實時性高要求的應(yīng)用越來越多(比如聊天、視頻直播),于是當(dāng)時協(xié)議規(guī)定的某些特性，已經(jīng)無法滿足現(xiàn)代網(wǎng)絡(luò)的需求了。
二、HTTP/1.1的缺陷
1.高延遲--帶來頁面加載速度的降低
雖然近幾年來網(wǎng)絡(luò)帶寬增長非常快，然而我們卻并沒有看到網(wǎng)絡(luò)延遲有對應(yīng)程度的降低。網(wǎng)絡(luò)延遲問題主要由于隊頭阻塞(Head-Of-Line Blocking),導(dǎo)致帶寬無法被充分利用。
隊頭阻塞是指當(dāng)順序發(fā)送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一并被阻塞，會導(dǎo)致客戶端遲遲收不到數(shù)據(jù)。針對隊頭阻塞,人們嘗試過以下辦法來解決:
.icon1 {
background: url(data:image/png;base64,<data>)
no
-repeat;
}
.icon2 {
background: url(data:image/png;base64,<data>)
no
-repeat;
}
2.無狀態(tài)特性--帶來的巨大HTTP頭部
由于報文Header一般會攜帶"User Agent""Cookie""Accept""Server"等許多固定的頭字段（如下圖），多達幾百字節(jié)甚至上千字節(jié)，但Body卻經(jīng)常只有幾十字節(jié)（比如GET請求、 204/301/304響應(yīng)），成了不折不扣的“大頭兒子”。Header里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀尽８氖牵汕先f的請求響應(yīng)報文里有很多字段值都是重復(fù)的，非常浪費。
3.明文傳輸--帶來的不安全性
HTTP/1.1在傳輸數(shù)據(jù)時，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗證對方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性。
你有沒有聽說過"免費WiFi陷阱”之類的新聞呢？黑客就是利用了HTTP明文傳輸?shù)娜秉c，在公共場所架設(shè)一個WiFi熱點開始“釣魚”，誘騙網(wǎng)民上網(wǎng)。一旦你連上了這個WiFi熱點，所有的流量都會被截獲保存，里面如果有銀行卡號、網(wǎng)站密碼等敏感信息的話那就危險了，黑客拿到了這些數(shù)據(jù)就可以冒充你為所欲為。
4.不支持服務(wù)器推送消息
三、SPDY 協(xié)議與 HTTP/2 簡介
1.SPDY 協(xié)議
上面我們提到,由于HTTP/1.x的缺陷，我們會引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個域名等等的方式來提高性能。不過這些優(yōu)化都繞開了協(xié)議，直到2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決HTTP/1.1效率不高的問題。谷歌推出SPDY，才算是正式改造HTTP協(xié)議本身。降低延遲，壓縮header等等，SPDY的實踐證明了這些優(yōu)化的效果，也最終帶來HTTP/2的誕生。
HTTP/1.1有兩個主要的缺點：安全不足和性能不高，由于背負(fù)著 HTTP/1.x 龐大的歷史包袱,所以協(xié)議的修改,兼容性是首要考慮的目標(biāo)，否則就會破壞互聯(lián)網(wǎng)上無數(shù)現(xiàn)有的資產(chǎn)。如上圖所示, SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。
SPDY 協(xié)議在Chrome瀏覽器上證明可行以后，就被當(dāng)作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。
2.HTTP/2 簡介
2015年，HTTP/2 發(fā)布。HTTP/2是現(xiàn)行HTTP協(xié)議（HTTP/1.x）的替代，但它不是重寫，HTTP方法/狀態(tài)碼/語義都與HTTP/1.x一樣。HTTP/2基于SPDY，專注于性能，最大的一個目標(biāo)是在用戶和網(wǎng)站間只用一個連接（connection）。從目前的情況來看，國內(nèi)外一些排名靠前的站點基本都實現(xiàn)了HTTP/2的部署，使用HTTP/2能帶來20%~60%的效率提升。
HTTP/2由兩個規(guī)范（Specification）組成：
四、HTTP/2 新特性
1.二進制傳輸
HTTP/2傳輸數(shù)據(jù)量的大幅減少,主要有兩個原因:以二進制方式傳輸和Header 壓縮。我們先來介紹二進制傳輸,HTTP/2 采用二進制格式傳輸數(shù)據(jù)，而非HTTP/1.x 里純文本形式的報文 ，二進制協(xié)議解析起來更高效。HTTP/2 將請求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進制編碼。
它把TCP協(xié)議的部分特性挪到了應(yīng)用層，把原來的"Header+Body"的消息"打散"為數(shù)個小片的二進制"幀"(Frame),用"HEADERS"幀存放頭數(shù)據(jù)、"DATA"幀存放實體數(shù)據(jù)。HTP/2數(shù)據(jù)分幀后"Header+Body"的報文結(jié)構(gòu)就完全消失了，協(xié)議看到的只是一個個的"碎片"。
HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個或多個幀組成。多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流標(biāo)識可以重新組裝。
2.Header 壓縮
HTTP/2并沒有使用傳統(tǒng)的壓縮算法，而是開發(fā)了專門的"HPACK”算法，在客戶端和服務(wù)器兩端建立“字典”，用索引號表示重復(fù)的字符串，還采用哈夫曼編碼來壓縮整數(shù)和字符串，可以達到50%~90%的高壓縮率。
具體來說:
例如下圖中的兩個請求， 請求一發(fā)送了所有的頭部字段，第二個請求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷
3.多路復(fù)用
在 HTTP/2 中引入了多路復(fù)用的技術(shù)。多路復(fù)用很好的解決了瀏覽器限制同一個域名下的請求數(shù)量的問題，同時也接更容易實現(xiàn)全速傳輸，畢竟新開一個 TCP 連接都需要慢慢提升傳輸速度。
大家可以通過 該鏈接 直觀感受下 HTTP/2 比 HTTP/1 到底快了多少。
在 HTTP/2 中，有了二進制分幀之后，HTTP /2 不再依賴 TCP 鏈接去實現(xiàn)多流并行了，在 HTTP/2中,
這一特性，使性能有了極大提升：
如上圖所示，多路復(fù)用的技術(shù)可以只通過一個 TCP 連接就可以傳輸所有的請求數(shù)據(jù)。
4.Server Push
HTTP2還在一定程度上改變了傳統(tǒng)的“請求-應(yīng)答”工作模式，服務(wù)器不再是完全被動地響應(yīng)請求，也可以新建“流”主動向客戶端發(fā)送消息。比如，在瀏覽器剛請求HTML的時候就提前把可能會用到的JS、CSS文件發(fā)給客戶端，減少等待的延遲，這被稱為"服務(wù)器推送"（ Server Push，也叫 Cache push）
例如下圖所示,服務(wù)端主動把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時再發(fā)送這些請求。
另外需要補充的是,服務(wù)端可以主動推送，客戶端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。主動推送也遵守同源策略，換句話說，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方確認(rèn)才行。
5.提高安全性
出于兼容的考慮，HTTP/2延續(xù)了HTTP/1的“明文”特點，可以像以前一樣使用明文傳輸數(shù)據(jù)，不強制使用加密通信，不過格式還是二進制，只是不需要解密。
但由于HTTPS已經(jīng)是大勢所趨，而且主流的瀏覽器Chrome、Firefox等都公開宣布只支持加密的HTTP/2，所以“事實上”的HTTP/2是加密的。也就是說，互聯(lián)網(wǎng)上通常所能見到的HTTP/2都是使用"https”協(xié)議名，跑在TLS上面。HTTP/2協(xié)議定義了兩個字符串標(biāo)識符：“h2"表示加密的HTTP/2，“h2c”表示明文的HTTP/2。
六、HTTP/3 新特性
1.HTTP/2 的缺點
雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，主要是底層支撐的 TCP 協(xié)議造成的。HTTP/2的缺點主要有以下幾點：
HTTP/2都是使用TCP協(xié)議來傳輸?shù)模绻褂肏TTPS的話，還需要使用TLS協(xié)議進行安全傳輸，而使用TLS也需要一個握手過程，這樣就需要有兩個握手延遲過程：
①在建立TCP連接的時候，需要和服務(wù)器進行三次握手來確認(rèn)連接成功，也就是說需要在消耗完1.5個RTT之后才能進行數(shù)據(jù)傳輸。
②進行TLS連接，TLS有兩個版本——TLS1.2和TLS1.3，每個版本建立連接所花的時間不同，大致是需要1~2個RTT。
總之，在傳輸數(shù)據(jù)之前，我們需要花掉 3～4 個 RTT。
上文我們提到在HTTP/2中，多個請求是跑在一個TCP管道中的。但當(dāng)出現(xiàn)了丟包時，HTTP/2 的表現(xiàn)反倒不如 HTTP/1 了。因為TCP為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認(rèn)，HTTP/2出現(xiàn)丟包時，整個 TCP 都要開始等待重傳，那么就會阻塞該TCP連接中的所有請求（如下圖）。而對于 HTTP/1.1 來說，可以開啟多個 TCP 連接，出現(xiàn)這種情況反到只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。
讀到這里，可能就會有人考慮為什么不直接去修改 TCP 協(xié)議？其實這已經(jīng)是一件不可能完成的任務(wù)了。因為 TCP 存在的時間實在太長，已經(jīng)充斥在各種設(shè)備中，并且這個協(xié)議是由操作系統(tǒng)實現(xiàn)的，更新起來不大現(xiàn)實。
2.HTTP/3簡介
Google 在推SPDY的時候就已經(jīng)意識到了這些問題，于是就另起爐灶搞了一個基于 UDP 協(xié)議的“QUIC”協(xié)議，讓HTTP跑在QUIC上而不是TCP上。而這個“HTTP over QUIC”就是HTTP協(xié)議的下一個大版本，HTTP/3。它在HTTP/2的基礎(chǔ)上又實現(xiàn)了質(zhì)的飛躍，真正“完美”地解決了“隊頭阻塞”問題。
QUIC 雖然基于 UDP，但是在原本的基礎(chǔ)上新增了很多功能，接下來我們重點介紹幾個QUIC新功能。不過HTTP/3目前還處于草案階段，正式發(fā)布前可能會有變動，所以本文盡量不涉及那些不穩(wěn)定的細(xì)節(jié)。
3.QUIC新功能
上面我們提到QUIC基于UDP，而UDP是“無連接”的，根本就不需要“握手”和“揮手”，所以就比TCP來得快。此外QUIC也實現(xiàn)了可靠傳輸，保證數(shù)據(jù)一定能夠抵達目的地。它還引入了類似HTTP/2的“流”和“多路復(fù)用”，單個“流"是有序的，可能會因為丟包而阻塞，但其他“流”不會受到影響。具體來說QUIC協(xié)議有以下特點：
雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎(chǔ)之上增加了一層來保證數(shù)據(jù)可靠性傳輸。它提供了數(shù)據(jù)包重傳、擁塞控制以及其他一些TCP中存在的特性。
由于QUIC是基于UDP的，所以QUIC可以實現(xiàn)使用0-RTT或者1-RTT來建立連接，這意味著QUIC可以用最快的速度來發(fā)送和接收數(shù)據(jù)，這樣可以大大提升首次打開頁面的速度。0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優(yōu)勢。
目前QUIC使用的是TLS1.3，相較于早期版本TLS1.3有更多的優(yōu)點，其中最重要的一點是減少了握手所花費的RTT個數(shù)。
和TCP不同，QUIC實現(xiàn)了在同一物理連接上可以有多個獨立的邏輯數(shù)據(jù)流（如下圖）。實現(xiàn)了數(shù)據(jù)流的單獨傳輸，就解決了TCP中隊頭阻塞的問題。
七、總結(jié)
參考文章
近在很多博客上都看到有關(guān)于WordPress集成百度實時推送的功能，雖然不知道具體效果如何，但是我想增加這個功能應(yīng)該總不會是壞事吧，所以就給自己的站點添加試試，以便下次更新Three主題的時候集成進去。
具體操作步驟如下：
1、獲取token值
我們只需要登錄百度站長平臺》網(wǎng)頁抓取》點擊【鏈接提交】，在右邊的頁面中的“鏈接提交”中選擇需要添加百度實時推送功能的站點，然后就可以看到這個站點的token值了。
PS：一個百度站長賬號有多個站點，這幾個站點的token值都是一樣的。
2、修改代碼，添加百度實時推送功能
把以下代碼中的token值（xxxxxxxxxxx）改為我們第一步獲取的token值（其他的不用修改），然后把這些代碼添加到主題目錄下的 functions.php 文件最后一個?>之前即可。
/**
* WordPress發(fā)布文章主動推送到百度，加快收錄保護原創(chuàng)【W(wǎng)ordPress通用方式】
* 文章地址：http://zhangge.net/5041.html
*/
if(!function_exists('Baidu_Submit')){
function Baidu_Submit($post_ID) {
$WEB_TOKEN='xxxxxxxxxxx'; //這里請換成你的網(wǎng)站的百度主動推送的token值
$WEB_DOMAIN=get_option('home');
//已成功推送的文章不再推送
if(get_post_meta($post_ID,'Baidusubmit',true)==1) return;
$url=get_permalink($post_ID);
$api='http://data.zz.baidu.com/urls?site='.$WEB_DOMAIN.'&token='.$WEB_TOKEN;
$request=new WP_Http;
$result=$request->request( $api , array( 'method'=> 'POST', 'body'=> $url , 'headers'=> 'Content-Type: text/plain') );
$result=json_decode($result['body'],true);
//如果推送成功則在文章新增自定義欄目Baidusubmit，值為1
if (array_key_exists('success',$result)) {
add_post_meta($post_ID, 'Baidusubmit', 1, true);
}
}
add_action('publish_post', 'Baidu_Submit', 0);
}
現(xiàn)在我們發(fā)布新文章，文章地址就會被主動推送到百度。被成功推送的文章，將自動出現(xiàn)如下自定義欄目：
為避免代碼重復(fù)推送的尷尬，如果你需要更新文章再次推送數(shù)據(jù)，那么在保存/更新文章之前，刪除或修改這個自定義欄目即可再次被推送。
Ps：雖然，主動推送的各種方法都支持一次推送多條數(shù)據(jù)，從我個人的經(jīng)驗來看，對于老文章沒必要再次推送，頻繁推送容易導(dǎo)致百度“翻臉”！
特別說明：
如果按以上步驟正確操作后，在發(fā)布新文章時自定義欄目中不會出現(xiàn)我們期望的baidusubmit，說明實時推送給百度不成功，說明所使用的主機的 curl_exec()函數(shù)被禁用了。這個時候，我們只需要把以下代碼替換掉第二步的代碼即可。
/**
* WordPress發(fā)布文章主動推送到百度，加快收錄保護原創(chuàng)【file_get_contents方式】
* 文章地址：http://zhangge.net/5041.html
*/
if(!function_exists('Baidu_Submit')) {
function Baidu_Submit($post_ID) {
$WEB_TOKEN='xxxxxxxxx'; //這里換成你的網(wǎng)站的百度主動推送的token值
$WEB_DOMAIN=get_option('home');
//已成功推送的文章不再推送
if(get_post_meta($post_ID,'Baidusubmit',true)==1) return;
$url=get_permalink($post_ID);
$api='http://data.zz.baidu.com/urls?site='.$WEB_DOMAIN.'&token='.$WEB_TOKEN;
$data=array (
'http'=> array (
'method'=> 'POST',
'header'=> "Content-Type: text/plain",
"Content-Length: ".strlen($url)."rn",
'content'=> $url
)
);
$data=stream_context_create($data);
$result=file_get_contents($api, false, $data);
$result=json_decode($result,true);
//如果推送成功則在文章新增自定義欄目Baidusubmit，值為1
if (array_key_exists('success',$result)) {
add_post_meta($post_ID, 'Baidusubmit', 1, true);
}
}
add_action('publish_post', 'Baidu_Submit', 0);
}
文中涉及的技術(shù)和代碼均來自于張戈博主分享的《WordPress發(fā)布文章主動推送到百度，加快收錄保護原創(chuàng)》。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
