郵政編碼在國内使用得越來越少了，以前還有一些做郵編查詢的網站現在都看不到了，不過我們的郵編庫✉️網站一直都在，而且還在不斷更新和擴展。

　　這裡介紹一個我們今年推出的地址郵政編碼數據庫子欄目，這個站主要特點是海量單位的地址信息及其

　　這是一篇記錄我過春節前後與同事商議網站内容和質量問題時候的博客，主要要點如下：

• 内容質量>>内容數量，不再堆積和追求數量
• 别人已有内容，我們再做的意義不大（如中文字典、成語詞典），除非有創新

　　MediaWiki和Drupal都自帶了站内搜索功能，我們多年都是直接調用，隻在少數情況下嘗試其它的，例如✉郵編庫網站因為數據量過大，Wiki站的搜索常導緻MySQL數據庫卡住，後來改用了Sphinx才不再卡住，但搜索結果不盡如意，有一些莫名其妙的不相幹結果，估計是沒有把Sphinx摸透、沒有專門加對中文的分詞包吧。

　　Drupal站也嘗試安裝過Apache Solr Search，感覺太複雜了，勉強用了一下，沒有深入研究。Drupal站還用Views來進行過搜索、安裝過Auto Complete，以及直接用SQL語句來進行搜索。

　　另外，

　　Drupal裡面Views功能很方便、強大，而在PHP程序中調用Views的Page或者Block也很需要，有時還可以起到替代寫SQL語句的作用，不過需要帶參數變量Block的調用不太常見，以前用過也老是忘記調用辦法，昨天又花時間找了一下，現在就記錄下面，免得以後又到處去找。

views_embed_view('views_name', 'page_or_block_id', 'variable');

　　詳情請看Drupal官方網站中的API文檔：views_embed_view

　　春節以後網站流量逐步回升，剛剛過去的2019年3月基本恢複到以前正常狀态，甚至有些站達到流量新高，不過服務器的資源偶爾也會報警，特别是遇到有大量采集或者攻擊的情況時，這很影響用戶體驗，我們也不得不花費大量時間來排查、屏蔽采集🙁。

　　前些天遇到“服務器上的所有網站疑似遇到攻擊”更是耽誤了我們兩天的時間來對付，這兩天用戶訪問也受到一定影響。在這個排查過程中，我們發現湧來的峰值流量是我們正常流量的2倍以上，如果我們的服務器配置資源足夠的話，那比較小的攻擊或者采集是無需采取措施的👌。

　　最近廣告聯盟的單價有所回升，我們還拓展

　　查号吧☎這個網站有很多年曆史了，1998年就開始提供長途電話區号查詢服務，2008年使用Wiki系統開放用戶提交電話号碼、曝光騙子，去年開始又增加了一個子欄目：電話号碼庫📞，我們主動來收集整理企事業單位的固定電話号碼（考慮到隐私問題，暫不提供手機号碼數據）

　　前一陣子突然接到法院遞送的EMS，打開看是我們公司被北京某圖片公司告了，我們一個很多年前的網站上有一幅圖片被訴侵犯了該公司的版權。

　　我們這網站是2009年建的，對方提供的證據截圖也顯示有一個頁面是2009年編輯的，

　　今年1月份記錄了一篇《清除百度MIP緩存，糾正跳轉錯誤》，當時是在百度移動搜索(m.baidu.com或者baidu app)中的搜索結果跳到錯誤的MIP頁面上，通過清除該域名下所有MIP緩存解決的，估計是百度的移動網頁索引中哪裡出了問題。

　　時隔一個多月，2月中旬後再次出現百度移動搜索中的搜索結果跳轉到錯誤的網址，而這次不是MIP頁面，而是普通的響應式網頁頁面，在移動搜索結果中顯示的網頁标題都是對的，就是點擊後到了錯誤的網址，例如統一都跳轉到 www.example.com/xxx/node/40933 ，裡面的内容明顯不匹配，而對應的百度PC搜索(www.b

　　網站遇到采集者是很常見的事情，因為采集太快太多導緻我們服務器負載過高的事情也時有發生，我們一般都是收到網站打開太慢或者服務器負載過高報警的消息後及時進行處理，在apache設置.htaccess上把該屏蔽的屏蔽就可以了，偶爾需要用到ipt

　　這兩年我們新建網站多數都采用了《在Drupal中直接導入、使用數據庫》這篇文章中說的辦法，而沒有用以前新建内容類型、導入到Drupal的Node中的辦法，這對于數據量大、改動不大、讀取多、寫入少的需求很合适。

　　偶爾遇到需要修改、删除的事情，我們就是到阿裡雲RDS管理後台，Web界面來操作或者用SQL語句來進行，比以前在Node頁面進行編輯要麻煩，但更改量不大的情況下也可以接受。

　　最近要用的一個新站也是用直接建表方式來搭建的，但内容需要人工來修改完善，而且是長久都需要添加、維護信息的，再用以前導入RDS後台就顯得太麻煩了，于是想去找現成的