談談你對面向物件的理解

在我理解,面向物件是向現實世界模型的自然延伸，這是一種“萬物皆物件”的程式設計思想。在現實生活中的任何物體都可以歸為一類事物，而每一個個體都是一類事物的例項。面向物件的程式設計是以物件為中心，以訊息為驅動，所以程式=物件+訊息。

面向物件有三大特性，封裝、繼承和多型。

封裝就是將一類事物的屬性和行為抽象成一個類，使其屬性私有化，行為公開化，提高了資料的隱祕性的同時，使程式碼模組化。這樣做使得程式碼的複用性更高。

繼承則是進一步將一類事物共有的屬性和行為抽象成一個父類，而每一個子類是一個特殊的父類–有父類的行為和屬性，也有自己特有的行為和屬性。這樣做擴充套件了已存在的程式碼塊，進一步提高了程式碼的複用性。

如果說封裝和繼承是為了使程式碼重用，那麼多型則是為了實現介面重用。多型的一大作用就是為了解耦–為了解除父子類繼承的耦合度。如果說繼承中父子類的關係式IS-A的關係，那麼介面和實現類之之間的關係式HAS-A。簡單來說，多型就是允許父類引用(或介面)指向子類(或實現類)物件。很多的設計模式都是基於面向物件的多型性設計的。

總結一下，如果說封裝和繼承是面向物件的基礎，那麼多型則是面向物件最精髓的理論。掌握多型必先了解介面，只有充分理解接口才能更好的應用多型。

Redis怎麼和資料庫同步

方案1：我們會先去redis中判斷資料是否存在，如果存在，則直接返回快取好的資料。而如果不存在的話，就會去資料庫中，讀取資料，並把資料快取到Redis中。適用場合：如果資料量比較大，但不是經常更新的情況(比如使用者排行)

方案2：先去redis中判斷資料是否存在，如果存在，則直接更新對應的資料(這一步會把對應更新過的key記錄下來，比如也儲存到redis中比如：key為：save_update_keys【用-push列表記錄】)，並把更新後的資料返回給頁面。而如果不存在的話，就會去先更新資料庫中內容，然後把資料儲存一份到Redis中。

Java的併發包提供了三個常用的併發佇列

分別是：ConcurrentLinkedQueue 、 LinkedBlockingQueue 和 ArrayBlockingQueue。

ArrayBlockingQueue是初始容量固定的阻塞佇列，我們可以用來作為資料庫模組成功競拍的佇列，比如有10個商品，那麼我們就設定一個10大小的陣列佇列。

ConcurrentLinkedQueue使用的是CAS原語無鎖佇列實現，是一個非同步佇列，入隊的速度很快，出隊進行了加鎖，效能稍慢。

LinkedBlockingQueue也是阻塞的佇列，入隊和出隊都用了加鎖，當隊空的時候執行緒會暫時阻塞。

單點登入原理

使用者首次登入時流程如下：

1.使用者瀏覽器訪問系統A需登入受限資源。

2.系統A發現該請求需要登入，將請求重定向到認證中心，進行登入。

3.認證中心呈現登入頁面，使用者登入，登入成功後，認證中心重定向請求到系統A，並附上認證通過令牌。

4.系統A與認證中心通訊，驗證令牌有效,證明使用者已登入。

5.系統A將受限資源返給使用者。

已登入使用者首次訪問應用群中系統B時：

瀏覽器訪問另一應用B需登入受限資源。

系統B發現該請求需要登入，將請求重定向到認證中心，進行登入。

認證中心發現已經登入，即重定向請求響應到系統B，附帶上認證令牌。

系統B與認證中心通訊，驗證令牌有效,證明使用者已登入。

系統B將受限資源返回給客戶端。

登入狀態判斷問題（重點[全域性會話id：CASTGC,區域性會話id：JSessionID]）

使用者到認證中心登入後，使用者和認證中心之間建立起了會話，我們把這個會話稱為全域性會話。當用戶後續訪問系統應用時，我們不可能每次應用請求都到認證中心去判定是否登入，這樣效率非常低下，這也是單Web應用不需要考慮的。

我們可以在系統應用和使用者瀏覽器之間建立起區域性會話，區域性會話保持了客戶端與該系統應用的登入狀態，區域性會話依附於全域性會話存在，全域性會話消失，區域性會話必須消失。

使用者訪問應用時，首先判斷區域性會話是否存在，如存在，即認為是登入狀態，無需再到認證中心去判斷。如不存在，就重定向到認證中心判斷全域性會話是否存在，如存在，按1提到的方式通知該應用，該應用與客戶端就建立起它們之間區域性會話，下次請求該應用，就不去認證中心驗證了。

Service Ticket安全問題

CAS 協議從幾個方面讓 Service Ticket 變得更加安全。

1.Service Ticket 只能使用一次。

CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會將服務端的快取中清除該 Ticket ，從而可以確保一個 Service Ticket 被使用兩次。

2.Service Ticket 在一段時間內失效。

假設使用者拿到 Service Ticket 之後，他請求 helloservice 的過程又被中斷了， Service Ticket 就被空置了，事實上，此時， Service Ticket 仍然有效。 CAS 規定 Service Ticket 只能存活一定的時間，然後 CAS Server 會讓它失效。通過在 web.xml 中配置下面的引數，可以讓 Service Ticket 在多少秒內失效。

<context-param>
<param-name>edu.yale.its.tp.cas.serviceTimeout</param-name>
<param-value>300</param-value>
</context-param>

該引數在業務應用的條件範圍內，越小越安全。

3.Service Ticket 是基於隨機數生成的。

Service Ticket 必須足夠隨機，如果 Service Ticket 生成規則被猜出（如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以構造下一個 Ticket ）， Hacker 就等於繞過 CAS 認證，直接訪問所有服務。

索引建立的原則

1．選擇唯一性索引

2．為經常需要排序、分組和聯合操作的欄位建立索引

3．為常作為查詢條件的欄位建立索引

4．限制索引的數目

5．儘量使用資料量少的索引

6．儘量使用字首來索引

7．刪除不再使用或者很少使用的索引

8 . 最左字首匹配原則，非常重要的原則。

9 .=和in可以亂序。

10 . 儘量選擇區分度高的列作為索引。

11 .索引列不能參與計算，保持列“乾淨”。

12 .儘量的擴充套件索引，不要新建索引。

Redis持久化方式RDB、AOF

Redis提供兩種方式進行持久化，一種是RDB持久化（原理是將Reids在記憶體中的資料庫記錄定時dump到磁碟上的RDB持久化），另外一種是AOF持久化（原理是將Reids的操作日誌以追加的方式寫入檔案）。

區別：

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，實際操作過程是fork一個子程序，先將資料集寫入臨時檔案，寫入成功後，再替換之前的檔案，用二進位制壓縮儲存。

AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文字的方式記錄，可以開啟檔案看到詳細的操作記錄。