第八章 最新技術（評論區留言獲取原件）

一、 Redis

1. Redis 的特點？

       Redis 是由義大利人 Salvatore Sanfilippo（網名： antirez）開發的一款記憶體快取記憶體資料庫。 Redis 全稱為：Remote Dictionary Server（遠端資料服務），該軟體使用 C 語言編寫，典型的 NoSQL 資料庫伺服器， Redis 是一個 key-value 儲存系統，它支援豐富的資料型別，如： string、 list、 set、 zset(sorted set)、 hash。
        Redis 本質上是一個 Key-Value 型別的記憶體資料庫，很像 memcached，整個 資料庫統統載入在記憶體當中進行操作，定期通過非同步操作把資料庫資料 flush 到硬碟 上進行儲存。因為是純記憶體操作， Redis 的效能非常出色，每秒可以處理超過 10 萬次讀寫操作，是已知效能最快的 Key-Value DB。
        Redis 的出色之處不僅僅是效能， Redis 最大的魅力是支援儲存多種資料結構，此外單 個 value 的最大限制是1GB，不像 memcached 只能儲存 1MB 的資料，另外 Redis 也可以對存入的 Key-Value 設定 expire 時間。
        Redis 的主要缺點是資料庫容量受到實體記憶體的限制，不能用作海量資料的高效能讀寫，因此 Redis 適合的場景主要侷限在較小資料量的高效能操作和運算上。

2. 為什麼 redis 需要把所有資料放到記憶體中？

        Redis 為了達到最快的讀寫速度將資料都讀到記憶體中，並通過非同步的方式將資料寫入磁碟。所以 redis 具有快速和
資料持久化的特徵。如果不將資料放在記憶體中，磁碟 I/O 速度為嚴重影響 redis 的效能。在記憶體越來越便宜的今天，
redis 將會越來越受歡迎。如果設定了最大使用的記憶體，則資料已有記錄數達到記憶體限值後不能繼續插入新值。

3. Redis 常見的效能問題都有哪些？如何解決？

（1）、 Master 寫記憶體快照， save 命令排程 rdbSave 函式，會阻塞主執行緒的工作，當快照比較大時對效能影響是非常大的，會間斷性暫停服務，所以 Master 最好不要寫記憶體快照。
（2）、 Master AOF 持久化，如果不重寫 AOF 檔案，這個持久化方式對效能的影響是最小的，但是 AOF 檔案會不斷增大， AOF 檔案過大會影響 Master 重啟的恢復速度。 Master 最好不要做任何持久化工作，包括記憶體快照和 AOF日誌檔案，特別是不要啟用記憶體快照做持久化,如果資料比較關鍵，某個 Slave 開啟 AOF 備份資料，策略為每秒同步一次。
（3）、 Master 呼叫 BGREWRITEAOF 重寫 AOF 檔案， AOF 在重寫的時候會佔大量的 CPU 和記憶體資源，導致服務 load 過高，出現短暫服務暫停現象。
（4）、 Redis 主從複製的效能問題，為了主從複製的速度和連線的穩定性， Slave 和 Master 最好在同一個區域網內。

4. Redis 最適合的場景有哪些？

（1）、會話快取（Session Cache）
（2）、全頁快取（FPC）
（3）、佇列
（4）、排行榜/計數器
（5）、釋出/訂閱

5. Memcache 與 Redis 的區別都有哪些？

（1）、儲存方式不同， Memcache 是把資料全部存在記憶體中，資料不能超過記憶體的大小，斷電後資料庫會掛掉。Redis 有部分存在硬碟上，這樣能保證資料的永續性。
（2）、資料支援的型別不同 memcahe 對資料型別支援相對簡單， redis 有複雜的資料型別。
（3）、使用底層模型不同 它們之間底層實現方式 以及與客戶端之間通訊的應用協議不一樣。 Redis 直接自己構建了 VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。
（4）、支援的 value 大小不一樣 redis 最大可以達到 1GB，而 memcache 只有 1MB。

6. Redis 用過 RedisNX 嗎？ Redis 有哪幾種資料結構？

反正我是不知道 redisnx 是什麼，度娘也不清楚，如果面試中問道自己沒有接觸過或者沒有聽過的技術可以直接
大膽的告訴他，沒有接觸過，或者沒有聽過。

Redis 的資料結構有五種，分別是：
String——字串
String 資料結構是簡單的 key-value 型別， value 不僅可以是 String，也可以是數字（當數字型別用 Long 可以表示的時候 encoding 就是整型，其他都儲存在 sdshdr 當做字串）。
Hash——字典
在 Memcached 中，我們經常將一些結構化的資訊打包成 hashmap，在客戶端序列化後儲存為一個字串的值
（一般是 JSON 格式），比如使用者的暱稱、年齡、性別、積分等。
List——列表
List 說白了就是連結串列（redis 使用雙端連結串列實現的 List），相信學過資料結構知識的人都應該能理解其結構。
Set——集合
Set 就是一個集合，集合的概念就是一堆不重複值的組合。利用 Redis 提供的 Set 資料結構，可以儲存一些集合性的資料。
Sorted Set——有序集合
和 Sets 相比， Sorted Sets 是將 Set 中的元素增加了一個權重引數 score，使得集合中的元素能夠按 score 進行有序排列，
1. 帶有權重的元素，比如一個遊戲的使用者得分排行榜
2.比較複雜的資料結構，一般用到的場景不算太多

7. Redis 的優缺點

優點：
a) 效能極高 – Redis 能支援超過 100K+ 每秒的讀寫頻率。
b) 豐富的資料型別 – Redis 支援二進位制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 資料型別操作。
c) 原子 – Redis 的所有操作都是原子性的，同時 Redis 還支援對幾個操作全並後的原子性執行。
attention 原子性定義：例如， A 想要從自己的帳戶中轉 1000 塊錢到 B 的帳戶裡。那個從 A 開始轉帳，到轉帳結束的這一個過程，稱之為一個事務。如果在 A 的帳戶已經減去了 1000 塊錢的時候，忽然發生了意外，比如停電什麼的，導致轉帳事務意外終止了，而此時 B 的帳戶裡還沒有增加 1000 塊錢。那麼，我們稱這個操作失敗了，要進行回滾。回滾就是回到事務開始之前的狀態，也就是回到 A 的帳戶還沒減 1000 塊的狀態， B 的帳戶的原來的狀態。此時A 的帳戶仍然有 3000 塊， B 的帳戶仍然有 2000 塊。我們把這種要麼一起成功（A 帳戶成功減少 1000，同時 B 帳戶成功增加 1000），要麼一起失敗（A 帳戶回到原來狀態， B 帳戶也回到原來狀態）的操作叫原子性操作。如果把一個事務可看作是一個程式,它要麼完整的被執行,要麼完全不執行，這種特性就叫原子性。
·d）豐富的特性 – Redis 還支援 publish/subscribe, 通知, key 過期等等特性。
缺點：
a） . 由於是記憶體資料庫，所以，單臺機器，儲存的資料量，跟機器本身的記憶體大小。雖然 redis 本身有 key 過期策略，但是還是需要提前預估和節約記憶體。如果記憶體增長過快，需要定期刪除資料。
b). 如果進行完整重同步，由於需要生成 rdb 檔案，並進行傳輸，會佔用主機的 CPU，並會消耗現網的頻寬。不過 redis2.8 版本，已經有部分重同步的功能，但是還是有可能有完整重同步的。比如，新上線的備機。
c). 修改配置檔案，進行重啟，將硬碟中的資料載入進記憶體，時間比較久。在這個過程中， redis 不能提供服務。

8. Redis 的持久化

RDB 持久化：該機制可以在指定的時間間隔內生成資料集的時間點快照（point-in-time snapshot）。
AOF 持久化：記錄伺服器執行的所有寫操作命令，並在伺服器啟動時，通過重新執行這些命令來還原資料集。 AOF檔案中的命令全部以 Redis 協議的格式來儲存，新命令會被追加到檔案的末尾。 Redis 還可以在後臺對 AOF 檔案進行重寫（rewrite），使得 AOF 檔案的體積不會超出儲存資料集狀態所需的實際大小無持久化：讓資料只在伺服器執行時存在。
同時應用 AOF 和 RDB：當 Redis 重啟時， 它會優先使用 AOF 檔案來還原資料集， 因為 AOF 檔案儲存的資料集通常比 RDB 檔案所儲存的資料集更完整。
RDB 的優缺點：
優點： RDB 是一個非常緊湊（compact）的檔案，它儲存了 Redis 在某個時間點上的資料集。 這種檔案非常適合用於進行備份： 比如說，你可以在最近的 24 小時內，每小時備份一次 RDB 檔案，並且在每個月的每一天，也備份一個 RDB 檔案。 這樣的話，即使遇上問題，也可以隨時將資料集還原到不同的版本。 RDB 非常適用於災難恢復（disaster recovery）：它只有一個檔案，並且內容都非常緊湊，可以（在加密後）將它傳送到別的資料中心，或者亞馬遜 S3 中。 RDB 可以最大化 Redis 的效能：父程序在儲存 RDB 檔案時唯一要做的就是 fork出一個子程序，然後這個子程序就會處理接下來的所有儲存工作，父程序無須執行任何磁碟 I/O 操作。 RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。
缺點：如果你需要儘量避免在伺服器故障時丟失資料，那麼 RDB 不適合你。 雖然 Redis 允許你設定不同的儲存點（save point）來控制儲存 RDB 檔案的頻率， 但是， 因為 RDB 檔案需要儲存整個資料集的狀態， 所以它並不是一個輕鬆的操作。 因此你可能會至少 5 分鐘才儲存一次 RDB 檔案。 在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的資料。每次儲存 RDB 的時候， Redis 都要 fork() 出一個子程序，並由子程序來進行實際的持久化工作。 在資料集比較龐大時， fork() 可能會非常耗時，造成伺服器在某某毫秒內停止處理客戶端； 如果資料集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。
AOF 的優缺點：
優點：1、使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設定不同的 fsync策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的預設策略為每秒鐘fsync 一次，在這種配置下， Redis 仍然可以保持良好的效能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的資料（fsync 會在後臺執行緒執行，所以主執行緒可以繼續努力地處理命令請求）。 AOF 檔案是一個只進行追加操作的日誌檔案（append only log）， 因此對 AOF 檔案的寫入不需要進行 seek ， 即使日誌因為某些原因而包含了未寫入完整的命令（比如寫入時磁碟已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
2、 Redis 可以在 AOF 檔案體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在建立新AOF 檔案的過程中，會繼續將命令追加到現有的 AOF 檔案裡面，即使重寫過程中發生停機，現有的AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢， Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，並開始對新 AOF 檔案進行追加操作。

二、 訊息佇列 ActiveMQ

1. 如何使用 ActiveMQ 解決分散式事務？

在網際網路應用中，基本都會有使用者註冊的功能。在註冊的同時，我們會做出如下操作：
1.收集使用者錄入資訊，儲存到資料庫
2.向用戶的手機或郵箱傳送驗證碼
等等…
如果是傳統的集中式架構，實現這個功能非常簡單：開啟一個本地事務，往本地資料庫中插入一條使用者資料，傳送驗證
碼，提交事物。
但是在分散式架構中，使用者和傳送驗證碼是兩個獨立的服務，它們都有各自的資料庫，那麼就不能通過本地事物保證操作的原子性。這時我們就需要用到 ActiveMQ（訊息佇列）來為我們實現這個需求。
在使用者進行註冊操作的時候，我們為該操作建立一條訊息，當用戶資訊儲存成功時，把這條訊息傳送到訊息佇列。驗證碼系統會監聽訊息，一旦接受到訊息，就會給該使用者傳送驗證碼。
問題：
1.如何防止訊息重複傳送？
解決方法很簡單：增加訊息狀態表。通俗來說就是一個賬本，用來記錄訊息的處理狀態，每次處理訊息之前，都去狀態表中查詢一次，如果已經有相同的訊息存在，那麼不處理，可以防止重複傳送。

2. 瞭解哪些訊息佇列？

ActiveMQ、 RabbitMQ、 kafka。
RabbitMQ
RabbitMQ 是使用 Erlang 編寫的一個開源的訊息佇列，本身支援很多的協議： AMQP， XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合於企業級的開發。同時實現了 Broker 構架，這意味著訊息在傳送給客戶端時先在中心佇列排隊。對路由，負載均衡或者資料持久化都有很好的支援。
ActiveMQ
ActiveMQ 是 Apache 下的一個子專案。 類似於 ZeroMQ，它能夠以代理人和點對點的技術實現佇列。同時類似於RabbitMQ，它少量程式碼就可以高效地實現高階應用場景。
Kafka/Jafka
Kafka 是 Apache 下的一個子專案，是一個高效能跨語言分散式釋出/訂閱訊息佇列系統，而 Jafka 是在 Kafka 之上孵化而來的，即 Kafka 的一個升級版。具有以下特性：快速持久化，可以在 O(1)的系統開銷下進行訊息持久化；高吞吐，在一臺普通的伺服器上既可以達到 10W/s 的吞吐速率；完全的分散式系統， Broker、 Producer、 Consumer 都原生自動支援分散式，自動實現負載均衡；支援 Hadoop 資料並行載入，對於像 Hadoop 的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。 Kafka 通過 Hadoop 的並行載入機制統一了線上和離線的訊息處理。 Apache Kafka 相對於 ActiveMQ 是一個非常輕量級的訊息系統，除了效能非常好之外，還是一個工作良好的分散式系統。
MQ 選型對比圖

3. ActiveMQ 如果訊息傳送失敗怎麼辦？

Activemq 有兩種通訊方式，點到點形式和釋出訂閱模式。
如果是點到點模式的話，如果訊息傳送不成功此 訊息預設會儲存到 activemq 服務端知道有消費者將其消費，所以此時訊息是不會丟失的。
如果是釋出訂閱模式的通訊方式，預設情況下只通知一次，如果接收不到此訊息就沒有了。這種場景只適 用於對訊息送達率要求不高的情況。如果要求訊息必須送達不可以丟失的話，需要配置持久訂閱。每個訂閱端定義一個 id，在訂閱是向 activemq 註冊。釋出訊息和接收訊息時需要配置傳送模式為持久化。此時 如果客戶端接收不到訊息，訊息會持久化到服務端，直到客戶端正常接收後為止。

三、 Dubbo

1. Dubbo 的容錯機制有哪些。

Dubbo 官網提出總共有六種容錯策略
Failover Cluster 模式
失敗自動切換，當出現失敗，重試其它伺服器。 (預設)
Failfast Cluster
快速失敗，只發起一次呼叫，失敗立即報錯。 通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。 通常用於寫入審計日誌等操作。
Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。 通常用於訊息通知操作。
Forking Cluster
並行呼叫多個伺服器，只要一個成功即返回。 通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過 forks=” 2”來設定最大並行數。
Broadcast Cluster
廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯。 (2.1.0 開始支援) 通常用於通知所有提供者更新快取或日誌等本地資源資訊。
總結： 在實際應用中查詢語句容錯策略建議使用預設 Failover Cluster ，而增刪改建議使用 Failfast Cluster 或者 使用 Failover Cluster（retries=” 0”） 策略 防止出現數據 重複新增等等其它問題！建議在設計介面時候把查詢介面方法單獨做一個介面提供查詢。

2. 使用 dubbo 遇到過哪些問題？

1.增加提供服務版本號和消費服務版本號.
這個具體來說不算是一個問題,而是一種問題的解決方案,在我們的實際工作中會面臨各種環境資源短缺的問題,也是很實際的問題,剛開始我們還可以提供一個服務進行相關的開發和測試,但是當有多個環境多個版本,多個任務的時候就不滿足我們的需求,這時候我們可以通過給提供方增加版本的方式來區分.這樣能夠剩下很多的物理資源,同時為今後更換介面定義釋出線上時，可不停機發布，使用版本號.
引用只會找相應版本的服務,例如
<dubbo:serviceinterface=“com.xxx.XxxService” ref=“xxxService” version=“1.0” />
<dubbo:referenceid=“xxxService” interface=“com.xxx.XxxService” version=“1.0” />

2.dubbo reference 註解問題
@Reference 只能在 springbean 例項對應的當前類中使用，暫時無法在父類使用；如果確實要在父類宣告一個引用，可通過配置檔案配置 dubbo:reference，然後在需要引用的地方跟引用 springbean 一樣就可以了.

3.出現 RpcException: No provider available for remote service 異常，表示沒有可用的服務提供者。
1). 檢查連線的註冊中心是否正確
2). 到註冊中心檢視相應的服務提供者是否存在
3). 檢查服務提供者是否正常執行
4. 服務提供者沒掛，但在註冊中心裡看不到
首先，確認服務提供者是否連線了正確的註冊中心，不只是檢查配置中的註冊中心地址，而且要檢查實際的網路連線。其次，看服務提供者是否非常繁忙，比如壓力測試，以至於沒有 CPU 片段向註冊中心傳送心跳，這種情況，減小壓力，將自動恢復。

3. Dubbo 的連線方式有哪些？

Dubbo 的客戶端和服務端有三種連線方式，分別是：廣播，直連和使用 zookeeper 註冊中心。
3.1、 Dubbo 廣播
這種方式是 dubbo 官方入門程式所使用的連線方式，但是這種方式有很多問題。
在企業開發中，不使用廣播的方式。
taotao-manager 服務端配置：

<!-- applicationContext-service.xml 檔案中 -->
<!-- 提供方應用資訊，用於計算機依賴關係 -->
<dubbo:application name=”taotao-manager-service” />
<!-- 使用 multicast 廣播暴露服務地址 -->
<dubbo:registry address=”multicast://224.5.6.7:1234” />
<!-- 使用 dubbo 協議在 20880 協議暴露服務 -->
<dubbo:protocol name=”dubbo” port=”20880” />
<!-- 宣告需要暴露的服務介面 -->
<dubbo:service interface=”com.taotao.manager.service.TestService” ref=”testServiceImpl” />
</bean>

客戶端配置 taotao-manager-web 的配置如下：

<!--springMVC.xml 檔案中 -->
<!-- 配置 dubbo 服務 -->
<dubbp:application name=”taotao-manager-web” />
<!-- 使用 multicast 廣播暴露服務地址 -->
<dubbo:registry address=”multicast://224.5.6.7:1234” />
<!-- 宣告要呼叫的服務 timeout 是設定連線超時最長時間，如果不設定，預設超時時間為 3 秒 -->
<dubbo:service interface=”com.taotao.manager.service.TestService” id=”testService”
timeout=”10000000” />
</bean>

3.2、 Dubbo 直連
這種方式在企業中一般在開發中環境中使用，但是生產環境很少使用，因為服務是直接呼叫，沒有使用註冊中心，很難對服務進行管理。 Dubbo 直連，首先要取消廣播，然後客戶端直接到指定需要的服務的 url 獲取服務即可。
服務端配置： taotao-manager 的修改如下，取消廣播，註冊中心地址為 N/A

<!-- applicationContext-service.xml 檔案中 -->
<!-- 提供方應用資訊，用於計算機依賴關係 -->
<dubbo:application name=”taotao-manager-service” />
<!-- <dubbo:registry address=”multicast://224.5.6.7:1234” /> -->
<!-- 使用 multicast 廣播暴露服務地址 -->
<dubbo:registry address=”N/A” />
<!-- 使用 dubbo 協議在 20880 協議暴露服務 -->
<dubbo:protocol name=”dubbo” port=”20880” />
<!-- 宣告需要暴露的服務介面 -->
<dubbo:service interface=”com.taotao.manager.service.TestService” ref=”testServiceImpl” />
</bean>

客戶端配置： taotao-manager-web 配置如下，取消廣播，從指定的 url 中獲取服務

<!--springMVC.xml 檔案中 -->
<!-- 配置 dubbo 服務 -->
<dubbp:application name=”taotao-manager-web” />
<!-- 使用 multicast 廣播暴露服務地址 -->
<!-- <dubbo:registry address=”multicast://224.5.6.7:1234” /> -->
<!-- 宣告要呼叫的服務 timeout 是設定連線超時最長時間，如果不設定，預設超時時間為 3 秒 -->
<dubbo:service interface=”com.taotao.manager.service.TestService” id=”testService”
timeout=”10000000” />
</bean>

3.3、 Dubbo 註冊中心
Dubbo 註冊中心和廣播註冊中心配置類似，不過需要指定註冊中心型別和註冊中心地址，這個時候就不是把服務資訊進行廣播了，而是告訴給註冊中心進行管理，這個時候我們就需要有一個註冊中心。
官方推薦使用 zookeeper 作為註冊中心。

3.31、 Zookeeper 介紹
zookeeper 在 dubbo 所處的位置：

Provider: 暴露服務的服務提供方。
Consumer: 呼叫遠端服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的呼叫次調和呼叫時間的監控中心。
Container: 服務執行容器。

呼叫關係說明：
0 .服務容器負責啟動，載入，執行服務提供者。
1. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一
臺呼叫。
5. 服務消費者和提供者， 在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。

四、 併發相關

1. 如何測試併發量？

可以使用 apache 提供的 ab 工具測試。
參考資料： https://blog.csdn.net/whynottrythis/article/details/46495309

五、 Nginx

1. Nginx 反向代理為什麼能夠提升伺服器效能？

        對於後端是動態服務來說，比如 Java 和 PHP。這類伺服器(如 JBoss 和 PHP-FPM)的 IO 處理能力往往不高。Nginx 有個好處是它會把 Request 在讀取完整之前 buffer 住，這樣交給後端的就是一個完整的 HTTP請求，從而提高後端的效率，而不是斷斷續續的傳遞(網際網路上連線速度一般比較慢)。 同樣， Nginx 也可以把response 給 buffer 住，同樣也是減輕後端的壓力。

2. Nginx 和 Apache 各有什麼優缺點?

nginx 相對 apache 的優點:
輕量級，同樣起 web 服務，比 apache 佔用更少的記憶體及資源
抗併發， nginx 處理請求是非同步非阻塞的，而 apache 則是阻塞型的，在高併發下 nginx 能保持低資源低消耗高效能
高度模組化的設計，編寫模組相對簡單
社群活躍，各種高效能模組出品迅速啊
apache 相對 nginx 的優點:
ewrite，比 nginx 的 rewrite 強大
模組超多，基本想到的都可以找到
少 bug， nginx 的 bug 相對較多
超穩定
一般來說，需要效能的 web 服務，用 nginx 。 如果不需要效能只求穩定，那就 apache 吧。

3. Nginx 多程序模型是如何實現高併發的？

        程序數與併發數不存在很直接的關係。這取決取 server 採用的工作方式。如果一個 server 採用一個程序負責一個 request 的方式，那麼程序數就是併發數。那麼顯而易見的，就是會有很多程序在等待中。等什麼？最多的應該是等待網路傳輸。
        Nginx 的非同步非阻塞工作方式正是利用了這點等待的時間。在需要等待的時候，這些程序就空閒出來待命了。因此表現為少數幾個程序就解決了大量的併發問題。 apache 是如何利用的呢，簡單來說：同樣的 4 個程序，如果採用一個程序負責一個 request 的方式，那麼，同時進來 4 個 request 之後，每個程序就負責其中一個，直至會話關閉。期間，如果有第 5 個 request 進來了。就無法及時反應了，因為 4 個程序都沒幹完活呢，因此，一般有個排程程序，每當新進來了一個 request，就新開個程序來處理。 nginx 不這樣，每進來一個 request，會有一個 worker 程序去處理。但不是全程的處理，處理到什麼程度呢？處理到可能發生阻塞的地方，比如向上遊（後端）伺服器轉發 request，並等待請求返回。那麼，這個處理的 worker 不會這麼傻等著，他會在傳送完請求後，註冊一個事件： “如果 upstream返回了，告訴我一聲，我再接著幹”。於是他就休息去了。此時，如果再有 request 進來，他就可以很快再按這種方式處理。而一旦上游伺服器返回了，就會觸發這個事件， worker 才會來接手，這個 request 才會接著往下走。
        由於 web server 的工作性質決定了每個 request 的大部份生命都是在網路傳輸中，實際上花費在 server 機器
上的時間片不多。這是幾個程序就解決高併發的祕密所在。 webserver 剛好屬於網路 io 密集型應用，不算是計算密
集型。非同步，非阻塞，使用 epoll，和大量細節處的優化。也正是 nginx 之所以然的技術基石。

六、 Zookeeper

1. 簡單介紹一下 zookeeper 以及 zookeeper 的原理。

        ZooKeeper 是一個分散式的，開放原始碼的分散式應用程式協調服務，是 Google 的 Chubby 一個開源的實現，是 Hadoop 和 Hbase 的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括:配置維護、域名服務、分散式同步、組服務等。
ZooKeeper 的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、 功能穩定的系統提供給使用者。
ZooKeeper 包含一個簡單的原語集， 提供 Java 和 C 的介面。
ZooKeeper 程式碼版本中，提供了分散式獨享鎖、選舉、佇列的介面，程式碼在 zookeeper-3.4.3\src\recipes。其中分佈鎖和佇列有 Java 和 C 兩個版本，選舉只有 Java 版本。
原理：
ZooKeeper 是以 Fast Paxos 演算法為基礎的， Paxos 演算法存在活鎖的問題，即當有多個 proposer 交錯提交時，有可能互相排斥導致沒有一個 proposer 能提交成功，而 Fast Paxos 作了一些優化，通過選舉產生一個 leader (領導者)，只有 leader 才能提交 proposer，具體 演算法可見 Fast Paxos。因此，要想弄懂 ZooKeeper 首先得對 Fast Paxos 有所瞭解。

ZooKeeper 的基本運轉流程:1、選舉 Leader。 2、同步資料。 3、選舉 Leader 過程中演算法有很多，但要達到的選舉標準是一致的。 4、 Leader 要具有最高的執行 ID，類似 root 許可權。 5、叢集中大多數的機器得到響應並 follow 選出的 Leader。

七、 solr

1. 簡單介紹一下 solr

        Solr 是一個獨立的企業級搜尋應用伺服器，它對外提供類似於 Web-service 的 API 介面。 使用者可以通過 http 請求，向搜尋引擎伺服器提交一定格式的 XML 檔案，生成索引;也可以 通過 Http Get 操作提出查詢請求，並得到 XML格式的返回結果。
特點:
Solr 是一個高效能，採用 Java5 開發，基於 Lucene 的全文搜尋伺服器。同時對其進行 了擴充套件，提供了比 Lucene更為豐富的查詢語言，同時實現了可配置、可擴充套件並對查詢效能 進行了優化，並且提供了一個完善的功能管理介面，是一款非常優秀的全文搜尋引擎。
工作方式:
文件通過 Http 利用 XML 加到一個搜尋集合中。查詢該集合也是通過 http 收到一個 XML/JSON 響應來實現。它的主要特性包括:高效、靈活的快取功能，垂直搜尋功能，高亮 顯示搜尋結果，通過索引複製來提高可用性，提供一套強大 Data Schema 來定義欄位，類 型和設定文字分析，提供基於 Web 的管理介面等。

2. solr 怎麼設定搜尋結果排名靠前？

可以設定文件中域的 boost 值， boost 值越高，計算出來的相關度得分就越高， 排名也就越靠前。此方法可以把熱點商品或者推廣商品的排名提高。

3. solr 中 IK 分詞器原理是什麼？

Ik 分詞器的分詞原理本質上是詞典分詞。 先在記憶體中初始化一個詞典，然後在分詞過程中挨個讀取字元，和字典中的字元相匹配，把文件中的所有的詞語拆分出來的過程。

八、 webService

1. 什麼是 webService？

WebService 是一種跨程式語言和跨作業系統平臺的遠端呼叫技術。所謂跨程式語言和跨操作平臺，就是說服務端程式採用 java 編寫，客戶端程式則可以採用其他程式語言編寫，反之亦然！跨作業系統平臺則是指服務端程式和客戶端程式可以在不同的作業系統上。

2. 常見的遠端呼叫技術

        RMI 是 java 語言本身提供的遠端通訊協議，穩定高效，是 EJB 的基礎。但它只能用於 JAVA 程式之間的通訊。
        Hessian 和 Burlap 是 caucho 公司提供的開源協議，基於 HTTP 傳輸，服務端不用開防火牆埠。協議的規範公開，可以用於任意語言。跨平臺有點小問題。
       Httpinvoker 是 SpringFramework 提供的遠端通訊協議，只能用於 JAVA 程式間的通訊，且服務端和客戶端必須使用 SpringFramework。
         Web service 是連線異構系統或異構語言的首選協議，它使用 SOAP 形式通訊，可以用於任何語言，目前的許多開發工具對其的支援也很好。
效率相比： RMI > Httpinvoker >= Hessian >> Burlap >> web service 什麼是 Highcharts

九、 Restful

1. 談談你對 restful 的理解以及在專案中的使用？

注意：下面回答內容來自百度百科。
一種軟體架構風格、設計風格，而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和伺服器互動類的軟體。 REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 RESTful。它結構清晰、符合標準、易於理解、擴充套件方便，所以正得到越來越多網站的採用。
給大家推薦如下一篇部落格，該部落格從多個維度講解了什麼是 Restful 並且給了 Restful 風格樣式的 API 介面。
https://blog.csdn.net/liuwenbiao1203/article/details/52351129

OTHER:
一、 傳統專案（2017-12-5-lyq）
1. 什麼是 BOS？
ERP 系統是企業資源計劃(Enterprise Resource Planning )的簡稱。
BOSS(Business & Operation Support )指的是業務運營支撐系統。
BOS 是 ERP 的整合與應用平臺。 BOS 遵循面向服務的架構體系，是一個面向業務的視覺化開發平臺；是一個
ERP 和第三方應用整合的技術平臺。它有效的解決了 ERP 應用的最主要矛盾－－－使用者需求個性化和傳統 ERP 軟
件標準化之間的矛盾。
BOS 與 ERP 是什麼關係？
ERP 是企業管理資訊化的全面解決方案， ERP 是基於 BOS 構建的。 ERP 滿足企業全面業務的標準應用； BOS
確保了企業 ERP 應用中的個性化需求完美實現。基於 BOS 的 ERP，可以為不同行業不同發展階段的企業構建靈活
的、可擴充套件的、全面整合的整體解決方案。
2. Activity 工作流
2.1 什麼是工作流？
（舉個栗子） 現在大多數公司的請假流程是這樣的：員工打電話（或網聊）向上級提出請假申請——上級口頭同
意——上級將請假記錄下來——月底將請假記錄上交公司——公司將請假錄入電腦。採用工作流技術的公司的請假流
程是這樣的：員工使用賬戶登入系統——點選請假——上級登入系統點選允許。就這樣，一個請假流程就結束了。有
人會問，那上級不用向公司提交請假記錄？公司不用將記錄錄入電腦？答案是，用的。但是這一切的工作都會在上級
感恩於心，回報於行。 面試寶典系列-Java
http://www.itheima.com Copyright© 2017 黑馬程式設計師
410
點選允許後自動執行！這就是工作流技術。
Georgakopoulos 給出的工作流定義是： 工作流是將一組任務組織起來以完成某個經營過程：定義了任務的觸
發順序和觸發條件，每個任務可以由一個或多個軟體系統完成，也可以由一個或一組人完成，還可以由一個或多個人
與軟體系統協作完。
2.2 工作流技術的優點
從上面的例子，很容易看出，工作流系統實現了工作流程的自動化，提高了企業運營效率、改善企業資源利
用、提高企業運作的靈活性和適應性、提高量化考核業務處理的效率、減少浪費（時間就是金錢）。而手工處理工
作流程，一方面無法對整個流程狀況進行有效跟蹤、瞭解，另一方面難免會出現人為的失誤和時間上的延時導致
效率低下，特別是無法進行量化統計，不利於查詢、報表及績效評估。
2.3 工作流生命週期
除了我們自行啟動（start）或者結束（finish）一個 Activity，我們並不能直接控制一個 Activity 的生
命狀態， 我們只能通過實現 Activity 生命狀態的表現——即回撥方法來達到管理 Activity 生命週期的變化。