樂觀鎖解決高併發

根本決解辦法只有一個：隊列，下面說的沒有用的

對於咱們開發的網站，若是網站的訪問量很是大的話，那麼咱們就須要考慮相關的併發訪問問題了。而併發問題是絕大部分的程序員頭疼的問題，

但話又說回來了，既然逃避不掉，那咱們就坦然面對吧~今天就讓咱們一塊兒來研究一下常見的併發和同步吧。

   爲了更好的理解併發和同步，咱們須要先明白兩個重要的概念:同步和異步

   一、同步和異步的區別和聯繫

         所謂同步，能夠理解爲在執行完一個函數或方法以後，一直等待系統返回值或消息，這時程序是出於阻塞的，只有接收到

        返回的值或消息後才往下執行其它的命令。

        異步，執行完函數或方法後，沒必要阻塞性地等待返回值或消息，只須要向系統委託一個異步過程，那麼當系統接收到返回

        值或消息時，系統會自動觸發委託的異步過程，從而完成一個完整的流程。

         同步在必定程度上能夠看作是單線程，這個線程請求一個方法後就待這個方法給他回覆，不然他不往下執行(死心眼)。

        異步在必定程度上能夠看作是多線程的(廢話，一個線程怎麼叫異步)，請求一個方法後，就無論了，繼續執行其餘的方法。

        

        同步就是一件事，一件事情一件事的作。
        異步就是，作一件事情，不引響作其餘事情。

        例如：吃飯和說話，只能一件事一件事的來，由於只有一張嘴。
                但吃飯和聽音樂是異步的，由於，聽音樂並不引響咱們吃飯。

 

        對於Java程序員而言，咱們會常常聽到同步關鍵字synchronized，假如這個同步的監視對象是類的話，那麼若是當一個對象

        訪問類裏面的同步方法的話，那麼其它的對象若是想要繼續訪問類裏面的這個同步方法的話，就會進入阻塞，只有等前一個對象

        執行完該同步方法後當前對象纔可以繼續執行該方法。這就是同步。相反，若是方法前沒有同步關鍵字修飾的話，那麼不一樣的對象

        能夠在同一時間訪問同一個方法，這就是異步。

      

        在補充一下(髒數據和不可重複讀的相關概念):

       髒數據

　　 髒讀就是指當一個事務正在訪問數據，而且對數據進行了修改，而這種修改尚未提交到數據庫中，這時，另一個事務也訪問這個數據，而後使用了這

個數據。由於這個數據是尚未提交的數據，那麼另一個事務讀到的這個數據是髒數據(Dirty Data)，依據髒數據所作的操做多是不正確的。

     不可重複讀

　　 不可重複讀是指在一個事務內，屢次 讀同一數據。在這個事務尚未結束時，另一個事務也訪問該同一數據。那麼，在第一個事務中的兩次讀數據之間，因爲第二個事務的修改，那麼第一個事務兩次 讀到的數據多是不同的。這樣就發生了在一個事務內兩次讀到的數據是不同的，所以稱爲是不可重複讀

 

         

 

   二、如何處理併發和同步

        今天講的如何處理併發和同同步問題主要是經過鎖機制。

       咱們須要明白，鎖機制有兩個層面。

       一種是代碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized，這裏我不在作過多的講解，

       感興趣的能夠參考:http://www.cnblogs.com/xiohao/p/4151408.html

       另一種是數據庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這裏咱們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖。

       悲觀鎖(Pessimistic Locking):       

       悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其餘事務，以及來自 外部系統的事務處理）修改持保守態度，所以，

       在整個數據處理過程當中，將數據處於鎖定狀態。

       悲觀鎖的實現，每每依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能 真正保證數據訪問的排他性，不然，即便在本系統

       中實現了加鎖機制，也沒法保證外部系 統不會修改數據）。 

       一個典型的倚賴數據庫的悲觀鎖調用： 

       select * from account where name=」Erica」 for update

       這條 sql 語句鎖定了 account 表中全部符合檢索條件（ name=」Erica」 ）的記錄。

       本次事務提交以前（事務提交時會釋放事務過程當中的鎖），外界沒法修改這些記錄。
       Hibernate 的悲觀鎖，也是基於數據庫的鎖機制實現。
       下面的代碼實現了對查詢記錄的加鎖：

       String hqlStr ="from TUser as user where user.name='Erica'";

        Query query = session.createQuery(hqlStr);

        query.setLockMode("user",LockMode.UPGRADE); // 加鎖

       List userList = query.list();// 執行查詢，獲取數據

       query.setLockMode 對查詢語句中，特定別名所對應的記錄進行加鎖（咱們爲 TUser 類指定了一個別名 「user」 ），這裏也就是對

      返回的全部 user 記錄進行加鎖。 

      觀察運行期 Hibernate 生成的 SQL 語句：
      select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id
      as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
      from t_user tuser0_ where (tuser0_.name='Erica' ) for update
     這裏 Hibernate 經過使用數據庫的 for update 子句實現了悲觀鎖機制。
      Hibernate 的加鎖模式有：
      Ø LockMode.NONE ： 無鎖機制。
      Ø LockMode.WRITE ： Hibernate 在 Insert 和 Update 記錄的時候會自動獲取
      Ø LockMode.READ ： Hibernate 在讀取記錄的時候會自動獲取。
      以上這三種鎖機制通常由 Hibernate 內部使用，如 Hibernate 爲了保證 Update
      過程當中對象不會被外界修改，會在 save 方法實現中自動爲目標對象加上 WRITE 鎖。
      Ø LockMode.UPGRADE ：利用數據庫的 for update 子句加鎖。
      Ø LockMode. UPGRADE_NOWAIT ： Oracle 的特定實現，利用 Oracle 的 for
      update nowait 子句實現加鎖。
      上面這兩種鎖機制是咱們在應用層較爲經常使用的，加鎖通常經過如下方法實現：
      Criteria.setLockMode
      Query.setLockMode
      Session.lock
      注意，只有在查詢開始以前（也就是 Hiberate 生成 SQL 以前）設定加鎖，纔會
      真正經過數據庫的鎖機制進行加鎖處理，不然，數據已經經過不包含 for update
      子句的 Select SQL 加載進來，所謂數據庫加鎖也就無從談起。

      爲了更好的理解select... for update的鎖表的過程，本人將要以mysql爲例，進行相應的講解

      一、要測試鎖定的情況，能夠利用MySQL的Command Mode ，開二個視窗來作測試。

          表的基本結構以下:

          

 

           表中內容以下:

           

 

          開啓兩個測試窗口，在其中一個窗口執行select * from ta for update0

          而後在另一個窗口執行update操做以下圖:

          

          等到一個窗口commit後的圖片以下:

          

           到這裏，悲觀鎖機制你應該瞭解一些了吧~

       

           須要注意的是for update要放到mysql的事務中，即begin和commit中，否者不起做用。

           至因而鎖住整個表仍是鎖住選中的行，請參考:

           http://www.cnblogs.com/xiohao/p/4385768.html

            至於hibernate中的悲觀鎖使用起來比較簡單，這裏就不寫demo了~感興趣的本身查一下就ok了~

           

          樂觀鎖(Optimistic Locking):        
         相對悲觀鎖而言，樂觀鎖機制採起了更加寬鬆的加鎖機制。悲觀鎖大多數狀況下依 靠數據庫的鎖機制實現，以保證操做最大程度的獨佔性。但隨之

而來的就是數據庫 性能的大量開銷，特別是對長事務而言，這樣的開銷每每沒法承受。 如一個金融系統，當某個操做員讀取用戶的數據，並在讀出的用戶數

據的基礎上進 行修改時（如更改用戶賬戶餘額），若是採用悲觀鎖機制，也就意味着整個操做過 程中（從操做員讀出數據、開始修改直至提交修改結果的全

過程，甚至還包括操做 員中途去煮咖啡的時間），數據庫記錄始終處於加鎖狀態，能夠想見，若是面對幾 百上千個併發，這樣的狀況將致使怎樣的後果。 樂

觀鎖機制在必定程度上解決了這個問題。

         樂觀鎖，大可能是基於數據版本   Version ）記錄機制實現。何謂數據版本？即爲數據增長一個版本標識，在基於數據庫表的版本解決方案中，通常是通

過爲數據庫表增長一個 「version」 字段來 實現。 讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提 交數據的版本數據與數據

庫表對應記錄的當前版本信息進行比對，若是提交的數據 版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。 對於上面修改用戶賬戶信息

的例子而言，假設數據庫中賬戶信息表中有一個 version 字段，當前值爲 1 ；而當前賬戶餘額字段（ balance ）爲 $100 。 操做員 A 此時將其讀出

（ version=1 ），並從其賬戶餘額中扣除 $50（ $100-$50 ）。 2 在操做員 A 操做的過程當中，操做員 B 也讀入此用戶信息（ version=1 ），並 從其賬

戶餘額中扣除 $20 （ $100-$20 ）。 3 操做員 A 完成了修改工做，將數據版本號加一（ version=2 ），連同賬戶扣 除後餘額（ balance=$50 ），提交

至數據庫更新，此時因爲提交數據版本大 於數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新爲 2 。 4 操做員 B 完成了操做，也將版本號加一

（ version=2 ）試圖向數據庫提交數 據（ balance=$80 ），但此時比對數據庫記錄版本時發現，操做員 B 提交的 數據版本號爲 2 ，數據庫記錄當前版

本也爲 2 ，不知足 「 提交版本必須大於記 錄當前版本才能執行更新 「 的樂觀鎖策略，所以，操做員 B 的提交被駁回。 這樣，就避免了操做員 B 用基於

version=1 的舊數據修改的結果覆蓋操做 員 A 的操做結果的可能。 從上面的例子能夠看出，樂觀鎖機制避免了長事務中的數據庫加鎖開銷（操做員 A

和操做員 B 操做過程當中，都沒有對數據庫數據加鎖），大大提高了大併發量下的系 統總體性能表現。 須要注意的是，樂觀鎖機制每每基於系統中的數據存儲

邏輯，所以也具有必定的局 限性，如在上例中，因爲樂觀鎖機制是在咱們的系統中實現，來自外部系統的用戶 餘額更新操做不受咱們系統的控制，所以可能

會形成髒數據被更新到數據庫中。在 系統設計階段，咱們應該充分考慮到這些狀況出現的可能性，並進行相應調整（如 將樂觀鎖策略在數據庫存儲過程當中實

現，對外只開放基於此存儲過程的數據更新途 徑，而不是將數據庫表直接對外公開）。 Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。若是不用考慮外

部系統對數 據庫的更新操做，利用 Hibernate 提供的透明化樂觀鎖實現，將大大提高咱們的 生產力。

Hibernate 中能夠經過 class 描述符的 optimistic-lock 屬性結合 version描述符指定。

如今，咱們爲以前示例中的 User 加上樂觀鎖機制。

 

1 ． 首先爲 User 的POJO class

       

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

package com.xiaohao.test;   public class User {     private Integer id;     private String userName;     private String password;     private int version;      public int getVersion() {      return version; }   public void setVersion( int version) {      this .version = version; }   public Integer getId() {      return id; }   public void setId(Integer id) {      this .id = id; }   public String getUserName() {      return userName; }   public void setUserName(String userName) {      this .userName = userName; }   public String getPassword() {      return password; }   public void setPassword(String password) {      this .password = password; }       public User() {}   public User(String userName, String password) {      super ();      this .userName = userName;      this .password = password; }               }

　　

        而後是User.hbm.xml

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<?xml version= "1.0" ?> <!DOCTYPE hibernate-mapping PUBLIC          "-//Hibernate/Hibernate Mapping DTD 3.0//EN"          "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" >   <hibernate-mapping package = "com.xiaohao.test" >        < class name= "User"  table= "user" optimistic-lock= "version" >                <id name= "id" >              <generator class = "native" />          </id>          <!--version標籤必須跟在id標籤後面-->          <version column= "version" name= "version"  />          <property name= "userName" />          <property name= "password" />                        </ class >         </hibernate-mapping>

注意 version 節點必須出如今 ID 節點以後。
這裏咱們聲明瞭一個 version 屬性，用於存放用戶的版本信息，保存在 User 表的version中
optimistic-lock 屬性有以下可選取值：
Ø none
無樂觀鎖
Ø version
經過版本機制實現樂觀鎖
Ø dirty
經過檢查發生變更過的屬性實現樂觀鎖
Ø all
經過檢查全部屬性實現樂觀鎖
其中經過 version 實現的樂觀鎖機制是 Hibernate 官方推薦的樂觀鎖實現，同時也
是 Hibernate 中，目前惟一在數據對象脫離 Session 發生修改的狀況下依然有效的鎖機
制。所以，通常狀況下，咱們都選擇 version 方式做爲 Hibernate 樂觀鎖實現機制。

2 ． 配置文件hibernate.cfg.xml和UserTest測試類

   hibernate.cfg.xml

  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

<!DOCTYPE hibernate-configuration PUBLIC          "-//Hibernate/Hibernate Configuration DTD 3.0//EN"          "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd" >   <hibernate-configuration> <session-factory>        <!-- 指定數據庫方言 若是使用jbpm的話，數據庫方言只能是InnoDB-->      <property name= "dialect" >org.hibernate.dialect.MySQL5InnoDBDialect</property>      <!-- 根據須要自動建立數據表 -->      <property name= "hbm2ddl.auto" >update</property>      <!-- 顯示Hibernate持久化操做所生成的SQL -->      <property name= "show_sql" > true </property>      <!-- 將SQL腳本進行格式化後再輸出 -->      <property name= "format_sql" > false </property>      <property name= "current_session_context_class" >thread</property>          <!-- 導入映射配置 -->      <property name= "connection.url" >jdbc:mysql: ///user</property>      <property name= "connection.username" >root</property>      <property name= "connection.password" > 123456 </property>      <property name= "connection.driver_class" >com.mysql.jdbc.Driver</property>      <mapping resource= "com/xiaohao/test/User.hbm.xml" />       </session-factory> </hibernate-configuration>

　　UserTest.java

    

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

package com.xiaohao.test;   import org.hibernate.Session; import org.hibernate.SessionFactory; import org.hibernate.Transaction; import org.hibernate.cfg.Configuration;   public class UserTest {      public static void main(String[] args) {          Configuration conf= new Configuration().configure();          SessionFactory sf=conf.buildSessionFactory();          Session session=sf.getCurrentSession();          Transaction tx=session.beginTransaction(); //      User user=new User("小浩","英雄"); //      session.save(user); //       session.createSQLQuery("insert into user(userName,password) value('張英雄16','123')") //                  .executeUpdate();          User user=(User) session.get(User. class , 1 );          user.setUserName( "221" ); //      session.save(user);                System.out.println( "恭喜您，用戶的數據插入成功了哦~~" );          tx.commit();      }   }

　　每次對 TUser 進行更新的時候，咱們能夠發現，數據庫中的 version 都在遞增。

下面咱們將要經過樂觀鎖來實現一下併發和同步的測試用例:

這裏須要使用兩個測試類，分別運行在不一樣的虛擬機上面，以此來模擬多個用戶同時操做一張表,同時其中一個測試類須要模擬長事務

UserTest.java

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

package com.xiaohao.test;   import org.hibernate.Session; import org.hibernate.SessionFactory; import org.hibernate.Transaction; import org.hibernate.cfg.Configuration;   public class UserTest {      public static void main(String[] args) {          Configuration conf= new Configuration().configure();          SessionFactory sf=conf.buildSessionFactory();          Session session=sf.openSession(); //      Session session2=sf.openSession();          User user=(User) session.createQuery( " from User user where user=5" ).uniqueResult(); //      User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();          System.out.println(user.getVersion()); //      System.out.println(user2.getVersion());          Transaction tx=session.beginTransaction();          user.setUserName( "101" );          tx.commit();                    System.out.println(user.getVersion()); //      System.out.println(user2.getVersion()); //      System.out.println(user.getVersion()==user2.getVersion()); //      Transaction tx2=session2.beginTransaction(); //      user2.setUserName("4468"); //      tx2.commit();            }   }

　　UserTest2.java

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

package com.xiaohao.test;   import org.hibernate.Session; import org.hibernate.SessionFactory; import org.hibernate.Transaction; import org.hibernate.cfg.Configuration;   public class UserTest2 {      public static void main(String[] args) throws InterruptedException {          Configuration conf= new Configuration().configure();          SessionFactory sf=conf.buildSessionFactory();          Session session=sf.openSession(); //      Session session2=sf.openSession();          User user=(User) session.createQuery( " from User user where user=5" ).uniqueResult();          Thread.sleep( 10000 ); //      User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();          System.out.println(user.getVersion()); //      System.out.println(user2.getVersion());          Transaction tx=session.beginTransaction();          user.setUserName( "100" );          tx.commit();                    System.out.println(user.getVersion()); //      System.out.println(user2.getVersion()); //      System.out.println(user.getVersion()==user2.getVersion()); //      Transaction tx2=session2.beginTransaction(); //      user2.setUserName("4468"); //      tx2.commit();            }   }

 

操做流程及簡單講解: 首先啓動UserTest2.java測試類，在執行到Thread.sleep(10000);這條語句的時候，當前線程會進入睡眠狀態。在10秒鐘以內

                            啓動UserTest這個類，在到達10秒的時候，咱們將會在UserTest.java中拋出下面的異常:

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Exception in thread "main" org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xiaohao.test.User# 5 ]      at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java: 1932 )      at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java: 2576 )      at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java: 2476 )      at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java: 2803 )      at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java: 113 )      at org.hibernate.engine.ActionQueue.execute(ActionQueue.java: 273 )      at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java: 265 )      at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java: 185 )      at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java: 321 )      at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java: 51 )      at org.hibernate.impl.SessionImpl.flush(SessionImpl.java: 1216 )      at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java: 383 )      at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java: 133 )      at com.xiaohao.test.UserTest2.main(UserTest2.java: 21 )

 

 UserTest2代碼將在 tx.commit() 處拋出 StaleObjectStateException 異 常，並指出版本檢查失敗，當前事務正在試圖提交一個過時數據。經過捕捉這個異常，我 們就能夠在樂觀鎖校驗失敗時進行相應處理

 

 

 

   三、常見併發同步案例分析

    案例一:訂票系統案例，某航班只有一張機票，假定有1w我的打開你的網站來訂票，問你如何解決併發問題(可擴展到任何高併發網站要考慮

               的併發讀寫問題)

    問題，1w我的來訪問，票沒出去前要保證你們都能看到有票，不可能一我的在看到票的時候別人就不能看了。到底誰能搶到，那得看這我的的「運氣」（網

             絡快慢等）

其次考慮的問題，併發，1w我的同時點擊購買，到底誰能成交？總共只有一張票。

首先咱們容易想到和併發相關的幾個方案 ：

鎖同步同步更多指的是應用程序的層面，多個線程進來，只能一個一個的訪問，java中指的是syncrinized關鍵字。鎖也有2個層面，一個是java中談到的對

象鎖，用於線程同步；另一個層面是數據庫的鎖；若是是分佈式的系統，顯然只能利用數據庫端的鎖來實現。

假定咱們採用了同步機制或者數據庫物理鎖機制，如何保證1w我的還能同時看到有票，顯然會犧牲性能，在高併發網站中是不可取的。使用hibernate後咱們

提出了另一個概念：樂觀鎖、悲觀鎖（即傳統的物理鎖）；

採用樂觀鎖便可解決此問題。樂觀鎖意思是不鎖定表的狀況下，利用業務的控制來解決併發問題，這樣即保證數據的併發可讀性又保證保存數據的排他性，保

證性能的同時解決了併發帶來的髒數據問題。

hibernate中如何實現樂觀鎖：

前提：在現有表當中增長一個冗餘字段，version版本號, long類型

原理：

1）只有當前版本號》=數據庫表版本號，才能提交

2）提交成功後，版本號version ++

實現很簡單：在ormapping增長一屬性optimistic-lock="version"便可，如下是樣例片斷

<hibernate-mapping>

<class name="com.insigma.stock.ABC" optimistic-lock="version" table="T_Stock" schema="STOCK">

案例2、股票交易系統、銀行系統，大數據量你是如何考慮的

首先，股票交易系統的行情表，每幾秒鐘就有一個行情記錄產生，一天下來就有（假定行情3秒一個） 股票數量×20×60*6 條記錄，一月下來這個表記錄數

量多大？ oracle中一張表的記錄數超過100w後 查詢性能就不好了，如何保證系統性能？

再好比，中國移動有上億的用戶量，表如何設計？把全部用於存在於一個表麼？

因此，大數量的系統，必須考慮表拆分-（表名字不同，可是結構徹底同樣），通用的幾種方式：（視狀況而定）

1）按業務分，好比 手機號的表，咱們能夠考慮 130開頭的做爲一個表，131開頭的另一張表 以此類推

2）利用oracle的表拆分機制作分表

3）若是是交易系統，咱們能夠考慮按時間軸拆分，當日數據一個表，歷史數據弄到其它表。這裏歷史數據的報表和查詢不會影響當日交易。

固然，表拆分後咱們的應用得作相應的適配。單純的or-mapping也許就得改動了。好比部分業務得經過存儲過程等

此外，咱們還得考慮緩存

這裏的緩存，指的不只僅是hibernate，hibernate自己提供了一級二級緩存。這裏的緩存獨立於應用，依然是內存的讀取，假如咱們能減小數據庫頻繁的訪

問，那對系統確定大大有利的。好比一個電子商務系統的商品搜索，若是某個關鍵字的商品常常被搜，那就能夠考慮這部分商品列表存放到緩存（內存中

去），這樣不用每次訪問數據庫，性能大大增長。

簡單的緩存你們能夠理解爲本身作一個hashmap，把常訪問的數據作一個key，value是第一次從數據庫搜索出來的值，下次訪問就能夠從map裏讀取，而不

讀數據庫；專業些的目前有獨立的緩存框架好比memcached 等，可獨立部署成一個緩存服務器。

 

四、常見的提升高併發下訪問的效率的手段

      首先要了解高併發的的瓶頸在哪裏？

     一、多是服務器網絡帶寬不夠

     2.可能web線程鏈接數不夠

     3.可能數據庫鏈接查詢上不去。

     根據不一樣的狀況，解決思路也不一樣。

1. 像第一種狀況能夠增長網絡帶寬，DNS域名解析分發多臺服務器。

2. 負載均衡，前置代理服務器nginx、apache等等

3. 數據庫查詢優化，讀寫分離，分表等等

   最後複製一些在高併發下面須要經常須要處理的內容:

• 儘可能使用緩存，包括用戶緩存，信息緩存等，多花點內存來作緩存，能夠大量減小與數據庫的交互，提升性能。

• 用jprofiler等工具找出性能瓶頸，減小額外的開銷。

• 優化數據庫查詢語句，減小直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢作優化）。

• 優化數據庫結構，多作索引，提升查詢效率。

• 統計的功能儘可能作緩存，或按天天一統計或定時統計相關報表，避免須要時進行統計的功能。

• 能使用靜態頁面的地方儘可能使用，減小容器的解析（儘可能將動態內容生成靜態html來顯示）。

• 解決以上問題後，使用服務器集羣來解決單臺的瓶頸問題。

 

好吧，簡單的高併發和同步就到這裏吧~~