標籤: 台中電動車

Redis 提供了兩種持久化方式，一種是基於快照形式的 RDB，另一種是基於日誌形式的 AOF，每種方式都有自己的優缺點，本文將介紹 Redis 這兩種持久化方式，希望閱讀本文後你對 Redis 的這兩種方式有更加全面、清晰的認識。

RDB 快照方式持久化

先從 RDB 快照方式聊起，RDB 是 Redis 默認開啟的持久化方式，並不需要我們單獨開啟，先來看看跟 RDB 相關的配置信息：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#   save ""
# 自動生成快照的觸發機制 中間的是時間，單位秒，後面的是變更數據 60 秒變更 10000 條數據則自動生成快照
save 900 1
save 300 10
save 60 10000

# 生成快照失敗時，主線程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否採用壓縮算法存儲
rdbcompression yes

# 數據恢復時是否檢測 RDB文件有效性
rdbchecksum yes

# The filename where to dump the DB
# RDB 快照生成的文件名稱
dbfilename dump.rdb

# 快照生成的路徑 AOF 也是存放在這個路徑下面
dir .

關於 RDB 相關配置信息不多，需要我們調整的就更少了，我們只需要根據自己的業務量修改生成快照的機制和文件存放路徑即可。

RDB 有兩種持久化方式：手動觸發 和 自動觸發，手動觸發使用以下兩個命令：

• save：會阻塞當前 Redis 服務器響應其他命令，直到 RDB 快照生成完成為止，對於內存 比較大的實例會造成長時間阻塞，所以線上環境不建議使用

• bgsave：Redis 主進程會 fork 一個子進程，RDB 快照生成有子進程來負責，完成之後，子進程自動結束，bgsave 只會在 fork 子進程的時候短暫的阻塞，這個過程是非常短的，所以推薦使用該命令來手動觸發

除了執行命令手動觸發之外，Redis 內部還存在自動觸發 RDB 的持久化機制，在以下幾種情況下 Redis 會自動觸發 RDB 持久化：

• 在配置中配置了 save 相關配置信息，如我們上面配置文件中的 save 60 10000 ，也可以把它歸類為“save m n”格式的配置，表示 m 秒內數據集存在 n 次修改時，會自動觸發 bgsave。

• 在主從情況下，如果從節點執行全量複製操作，主節點自動執行 bgsave 生成 RDB 文件併發送給從節點

• 執行 debug reload 命令重新加載 Redis 時，也會自動觸發 save 操作

• 默認情況下執行 shutdown 命令時，如果沒有開啟 AOF 持久化功能則自動執行 bgsave

上面就是 RDB 持久化的方式，可以看出 save 命令使用的比較少，大多數情況下使用的都是 bgsave 命令，所以這個 bgsave 命令還是有一些東西，那接下來我們就一起看看 bgsave 背後的原理，先從流程圖開始入手：

bgsave 命令大概有以下幾個步驟：

• 1、執行 bgsave 命令，Redis 主進程判斷當前是否存在正在執行的 RDB/AOF 子進程，如果存在， bgsave 命令直接返回不在往下執行。
• 2、父進程執行 fork 操作創建子進程，fork 操作過程中父進程會阻塞，fork 完成後父進程將不在阻塞可以接受其他命令。
• 3、子進程創建新的 RDB 文件，基於父進程當前內存數據生成臨時快照文件，完成後用新的 RDB 文件替換原有的 RDB 文件，並且給父進程發送 RDB 快照生成完畢通知

上面就是 bgsave 命令背後的一些內容，RDB 的內容就差不多了，我們一起來總結 RDB 持久化的優缺點，RDB 方式的優點：

• RDB 快照是某一時刻 Redis 節點內存數據，非常適合做備份，上傳到遠程服務器或者文件系統中，用於容災備份
• 數據恢復時 RDB 要遠遠快於 AOF

有優點同樣存在缺點，RDB 的缺點有：

• RDB 持久化方式數據沒辦法做到實時持久化/秒級持久化。我們已經知道了 bgsave 命令每次運行都要執行 fork 操作創建子進程，屬於重量級操作，頻繁執行成本過高。
• RDB 文件使用特定二進制格式保存，Redis 版本演進過程中有多個格式 的 RDB 版本，存在老版本 Redis 服務無法兼容新版 RDB 格式的問題

如果我們對數據要求比較高，每一秒的數據都不能丟，RDB 持久化方式肯定是不能夠滿足要求的，那 Redis 有沒有辦法滿足呢，答案是有的，那就是接下來的 AOF 持久化方式

AOF 持久化方式

Redis 默認並沒有開啟 AOF 持久化方式，需要我們自行開啟，在 redis.conf 配置文件中將 appendonly no 調整為 appendonly yes，這樣就開啟了 AOF 持久化，與 RDB 不同的是 AOF 是以記錄操作命令的形式來持久化數據的，我們可以查看以下 AOF 的持久化文件 appendonly.aof

*2
$6
SELECT
$1
0
*3
$3
set
$6
mykey1
$6
你好
*3
$3
set
$4
key2
$5
hello
*1
$8

大概就是長這樣的，具體的你可以查看你 Redis 服務器上的 appendonly.aof 配置文件，這也意味着我們可以在 appendonly.aof 文件中國修改值，等 Redis 重啟時將會加載修改之後的值。看似一些簡單的操作命令，其實從命令到 appendonly.aof 這個過程中非常有學問的，下面時 AOF 持久化流程圖：

在 AOF 持久化過程中有兩個非常重要的操作：一個是將操作命令追加到 AOF_BUF 緩存區，另一個是 AOF_buf 緩存區數據同步到 AOF 文件，接下來我們詳細聊一聊這兩個操作：

1、為什麼要將命令寫入到 aof_buf 緩存區而不是直接寫入到 aof 文件？

我們知道 Redis 是單線程響應，如果每次寫入 AOF 命令都直接追加到磁盤上的 AOF 文件中，這樣頻繁的 IO 開銷，Redis 的性能就完成取決於你的機器硬件了，為了提升 Redis 的響應效率就添加了一層 aof_buf 緩存層， 利用的是操作系統的 cache 技術，這樣就提升了 Redis 的性能，雖然這樣性能是解決了，但是同時也引入了一個問題，aof_buf 緩存區數據如何同步到 AOF 文件呢？由誰同步呢？這就是我們接下來要聊的一個操作：fsync 操作

2、aof_buf 緩存區數據如何同步到 aof 文件中？

aof_buf 緩存區數據寫入到 aof 文件是有 linux 系統去完成的，由於 Linux 系統調度機制周期比較長，如果系統故障宕機了，意味着一個周期內的數據將全部丟失，這不是我們想要的，所以 Linux 提供了一個 fsync 命令，fsync 是針對單個文件操作（比如這裏的 AOF 文件），做強制硬盤同步，fsync 將阻塞直到寫入硬盤完成后返回，保證了數據持久化，正是由於有這個命令，所以 redis 提供了配置項讓我們自行決定何時進行磁盤同步，redis 在 redis.conf 中提供了appendfsync 配置項，有如下三個選項：

# appendfsync always
appendfsync everysec
# appendfsync no

• always：每次有寫入命令都進行緩存區與磁盤數據同步，這樣保證不會有數據丟失，但是這樣會導致 redis 的吞吐量大大下降，下降到每秒只能支持幾百的 TPS ，這違背了 redis 的設計，所以不推薦使用這種方式
• everysec：這是 redis 默認的同步機制，雖然每秒同步一次數據，看上去時間也很快的，但是它對 redis 的吞吐量沒有任何影響，每秒同步一次的話意味着最壞的情況下我們只會丟失 1 秒的數據， 推薦使用這種同步機制，兼顧性能和數據安全
• no：不做任何處理，緩存區與 aof 文件同步交給系統去調度，操作系統同步調度的周期不固定，最長會有 30 秒的間隔，這樣出故障了就會丟失比較多的數據。

這就是三種磁盤同步策略，但是你有沒有注意到一個問題，AOF 文件都是追加的，隨着服務器的運行 AOF 文件會越來越大，體積過大的 AOF 文件對 redis 服務器甚至是主機都會有影響，而且在 Redis 重啟時加載過大的 AOF 文件需要過多的時間，這些都是不友好的，那 Redis 是如何解決這個問題的呢？Redis 引入了重寫機制來解決 AOF 文件過大的問題。

3、Redis 是如何進行 AOF 文件重寫的？

Redis AOF 文件重寫是把 Redis 進程內的數據轉化為寫命令同步到新 AOF 文件的過程，重寫之後的 AOF 文件會比舊的 AOF 文件占更小的體積，這是由以下幾個原因導致的：

• 進程內已經超時的數據不再寫入文件
• 舊的 AOF 文件含有無效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進程內數據直接生成，這樣新的AOF文件只保 留最終數據的寫入命令
• 多條寫命令可以合併為一個，如：lpush list a、lpush list b、lpush list c可以轉化為：lpush list a b c。為了防止單條命令過大造成客戶端緩衝區溢 出，對於 list、set、hash、zset 等類型操作，以 64 個元素為界拆分為多條。

重寫之後的 AOF 文件體積更小了，不但能夠節約磁盤空間，更重要的是在 Redis 數據恢復時，更小體積的 AOF 文件加載時間更短。AOF 文件重寫跟 RDB 持久化一樣分為手動觸發和自動觸發，手動觸發直接調用 bgrewriteaof 命令就好了，我們後面會詳細聊一聊這個命令，自動觸發就需要我們在 redis.conf 中修改以下幾個配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• auto-aof-rewrite-percentage：代表當前 AOF文件空間 （aof_current_size）和上一次重寫后 AOF 文件空間（aof_base_size）的比值，默認是 100%，也就是一樣大的時候
• auto-aof-rewrite-min-size：表示運行 AOF 重寫時 AOF 文件最小體積，默認為 64MB，也就是說 AOF 文件最小為 64MB 才有可能觸發重寫

滿足了這兩個條件，Redis 就會自動觸發 AOF 文件重寫，AOF 文件重寫的細節跟 RDB 持久化生成快照有點類似，下面是 AOF 文件重寫流程圖：

AOF 文件重寫也是交給子進程來完成，跟 RDB 生成快照很像，AOF 文件重寫在重寫期間建立了一個 aof_rewrite_buf 緩存區來保存重寫期間主進程響應的命令，等新的 AOF 文件重寫完成后，將這部分文件同步到新的 AOF 文件中，最後用新的 AOF 文件替換掉舊的 AOF 文件。需要注意的是在重寫期間，舊的 AOF 文件依然會進行磁盤同步，這樣做的目的是防止重寫失敗導致數據丟失，

Redis 持久化數據恢復

我們知道 Redis 是基於內存的，所有的數據都存放在內存中，由於機器宕機或者其他因素重啟了就會導致我們的數據全部丟失，這也就是要做持久化的原因，當服務器重啟時，Redis 會從持久化文件中加載數據，這樣我們的數據就恢復到了重啟前的數據，在數據恢復這一塊Redis 是如何實現的？我們先來看看數據恢復的流程圖：

Redis 的數據恢複流程比較簡單，優先恢復的是 AOF 文件，如果 AOF 文件不存在時則嘗試加載 RDB 文件，為什麼 RDB 的恢復速度比 AOF 文件快，但是還是會優先加載 AOF 文件呢？我個人認為是 AOF 文件數據更全面並且 AOF 兼容性比 RDB 強，需要注意的是當存在 RDB/AOF 時，如果數據加載不成功，Redis 服務啟動會失敗。

最後

目前互聯網上很多大佬都有 Redis 系列教程，如有雷同，請多多包涵了。原創不易，碼字不易，還希望大家多多支持。若文中有所錯誤之處，還望提出，謝謝。

歡迎掃碼關注微信公眾號：「平頭哥的技術博文」，和平頭哥一起學習，一起進步。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

福特（Ford）執行長 Mark Fields 於 4 月 28 日對外表示，福特正在開發能與特斯拉（Tesla） Model 3 與雪佛蘭（Chevrolet ） Bolt 純電動車匹敵的長程電動車，目標是要達到單次充電續航里程 200 英里，在越來越多車廠投入電動車製造的同時，福特打算「成為其中的佼佼者」，甚至是「坐上傲視群雄的位置」。此話一出，向電動車市場其他車廠宣戰的意味濃厚。

雖然 Fields 並未透露太多細節，但這還是福特高層第一次直接對外證實，公司正在研擬向特斯拉與雪佛蘭挑戰的電動車開發計畫。Fields 未提及確切的上市時間，僅表示該電動車將會取名為「Model E」，計畫將於 2019 年在福特本月初宣布要在墨西哥中部興建的新工廠進行組裝，該工廠預計於 2018 年投產。   有別於特斯拉 Model 3 及雪佛蘭 Bolt 為純電動車款，據研究公司 AutoForecast Solutions 指出，福特的 Model E 打算提供 3 種車型，包括油電混合動力車、插電式混合動力車與純電動車，且福特已經以 Model E 名稱申請商標註冊。   回溯至 2015 年 12 月，當時 Fields 曾對外宣布，福特將斥資 45 億美元推動電動車市場，要在 2020 年前，在產品陣容中，加入 13 款油電混合動力車或電動車型，且屆時福特所出產的車輛中，多達 40% 將會是電力驅動的車輛。   福特先前宣布將在 2017 年推出的電動車 Focus Electric 車型續航里程僅能達到 76 英里，即便將在今年秋季增加到 100 英里，不過，仍遠低於將於今年底推出的雪佛蘭 Bolt，以及預計 2 年內交車的特斯拉 Model 3 單次充電續航里程數。

（首圖來源： CC BY 2.0）

（本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

編寫powermock用例步驟：

• 類上面先寫這兩個註解@RunWith(PowerMockRunner.class)、@PrepareForTest(StudentService.class)
• 先模擬一個假對象即studentdao方法中的局部變量
• 用無參的方式new對象
• 再模擬這個對象被調用時，是否有返回，有返回值給出默認值，沒有用doNothing()
• 驗證有返回值使用assertEquals即可，無返回值使用Mockito.verify驗證

實際案例

接着上一篇文章中的代碼，修改下service中的代碼，這次我不通過構造器注入Dao,在方法中new一個StudentDao，創建一個名為StudentNewService的類。

具體示例代碼如下：

package com.rongrong.powermock.service;

import com.rongrong.powermock.dao.StudentDao;

/**
 * @author rongrong
 * @version 1.0
 * @date 2019/11/17 21:13
 */
public class StudentNewService {


    /**
     * 獲取學生個數
     * @return返回學生總數
     */
    public int getTotal() {
        StudentDao studentDao = new StudentDao();
        return studentDao.getTotal();
    }

    /**
     * 創建學生
     * @param student
     */
    public void createStudent(Student student) {
        StudentDao studentDao = new StudentDao();
        studentDao.createStudent(student);
    }
}

針對上面修改部分代碼，進行單元測試，以下代碼有採用傳統方式測試和採用powermock方式進行測試，具體代碼如下：

package com.rongrong.powermock.service;

import com.rongrong.powermock.dao.StudentDao;
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.fail;

/**
 * @author rongrong
 * @version 1.0
 * @date 2019/11/20 21:42
 */
@RunWith(PowerMockRunner.class)
@PrepareForTest(StudentNewService.class)
public class TestNewStudentService {

    /**
     * 傳統方式測試
     */
    @Test
    public void testGetStudentTotal() {
        StudentNewService studentNewService = new StudentNewService();
        int total = studentNewService.getTotal();
        assertEquals(total, 10);
    }

    /**
     * @desc測試有返回值類型 採用powermock進行測試獲取學生個數
     */
    @Test
    public void testGetStudentTotalWithPowerMock() {
        //先模擬一個假對象即studentdao方法中的局部變量
        StudentDao studentDao = PowerMockito.mock(StudentDao.class);
        try {
            //這句話我按照英文理解就是，我用無參的方式new了一個StudentDao對象
            PowerMockito.whenNew(StudentDao.class).withNoArguments().thenReturn(studentDao);
            //再模擬這個對象被調用時，我們默認假定返回10個證明調用成功
            PowerMockito.when(studentDao.getTotal()).thenReturn(10);
            //這裏就是service就不用再說了
            StudentNewService studentNewService = new StudentNewService();
            int total = studentNewService.getTotal();
            assertEquals(total, 10);
        } catch (Exception e) {
            fail("測試失敗了！！！");
            e.printStackTrace();
        }

    }

    /**
     * @desc測試的無返回值類型 採用powermock進行測試創建學生
     */
    @Test
    public void testCreateStudentWithPowerMock() {
        //先模擬一個假對象即studentdao方法中的局部變量
        StudentDao studentDao = PowerMockito.mock(StudentDao.class);
        try {
            //這句話我按照英文理解就是，我用無參的方式new了一個StudentDao對象
            PowerMockito.whenNew(StudentDao.class).withNoArguments().thenReturn(studentDao);
            Student student = new Student();
            //這句話註釋與否都能運行通過，也就是我只能判斷他是否被調用
            //PowerMockito.doNothing().when(studentDao).createStudent(student);
            //這裏就是service就不用再說了
            StudentNewService studentNewService = new StudentNewService();
            studentNewService.createStudent(student);
            Mockito.verify(studentDao).createStudent(student);
        } catch (Exception e) {
            fail("測試失敗了！！！");
            e.printStackTrace();
        }

    }

}

運行上面的測試用例，會發現第一個失敗，後面兩個都運行成功，即有返回值和無返回值類型的測試（void類型）。

 

 

注意：對於無返回值類型的測試，只能驗證其是否被調用，這裏還請注意。

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

Talk is cheap

CAS(Compare And Swap)，即比較並交換。是解決多線程并行情況下使用鎖造成性能損耗的一種機制，CAS操作包含三個操作數——內存位置（V）、預期原值（A）和新值(B)。如果內存位置的值與預期原值相匹配，那麼處理器會自動將該位置值更新為新值。否則，處理器不做任何操作。無論位置V的值是否等於A， 都將返回V原有的值。

CAS的含義是”我認為V的值應該是A，如果是，那我將V的值更新為B，否則不修改並告訴V的值實際是多少“

Show you my code

在單線程環境中分別使用無鎖，加鎖以及cas進行十組5億次累加運算，然後打印出平均耗時。

 /**
 * cas對比加鎖測試
 *
 * @author Jann Lee
 * @date 2019-11-21 0:12
 **/
public class CasTest {

    @Test
    public void test() {
        long times = 500_000_000;
        // 記錄耗時
        List<Long> elapsedTime4NoLock = new ArrayList<>(10);
        List<Long> elapsedTime4Synchronized = new ArrayList<>(10);
        List<Long> elapsedTime4ReentrantLock = new ArrayList<>(10);
        List<Long> elapsedTime4Cas = new ArrayList<>(10);

        // 進行10組試驗
        for (int j = 0; j < 10; j++) {
            // 無鎖
            long startTime = System.currentTimeMillis();
            for (long i = 0; i < times; i++) {
            }
            long endTime = System.currentTimeMillis();
            elapsedTime4NoLock.add(endTime - startTime);

            // synchronized 關鍵字（隱式鎖）
            startTime = endTime;
            for (long i = 0; i < times; ) {
                i = addWithSynchronized(i);
            }
            endTime = System.currentTimeMillis();
            elapsedTime4Synchronized.add(endTime - startTime);

            // ReentrantLock 顯式鎖
            startTime = endTime;
            ReentrantLock lock = new ReentrantLock();
            for (long i = 0; i < times; ) {
                i = addWithReentrantLock(i, lock);
            }
            endTime = System.currentTimeMillis();
            elapsedTime4ReentrantLock.add(endTime - startTime);

            // cas(AtomicLong底層是用cas實現)
            startTime = endTime;
            AtomicLong atomicLong = new AtomicLong();
            while (atomicLong.getAndIncrement() < times) {
            }
            endTime = System.currentTimeMillis();
            elapsedTime4Cas.add(endTime - startTime);
        }

        System.out.println("無鎖計算耗時: " + average(elapsedTime4NoLock) + "ms");
        System.out.println("synchronized計算耗時: " + average(elapsedTime4Synchronized) + "ms");
        System.out.println("ReentrantLock計算耗時: " + average(elapsedTime4ReentrantLock) + "ms");
        System.out.println("cas計算耗時: " + average(elapsedTime4Cas) + "ms");

    }

    /**
     * synchronized加鎖
     */
    private synchronized long addWithSynchronized(long i) {
        i = i + 1;
        return i;
    }

    /**
     * ReentrantLock加鎖
     */
    private long addWithReentrantLock(long i, Lock lock) {
        lock.lock();
        i = i + 1;
        lock.unlock();
        return i;
    }

    /**
     * 計算平均耗時
     */
    private double average(Collection<Long> collection) {
        return collection.stream().mapToLong(i -> i).average().orElse(0);
    }
}

從案例中我們可能看出在單線程環境場景下cas的性能要高於鎖相關的操作。當然，在競爭比較激烈的情況下性能可能會有所下降，因為要不斷的重試和回退或者放棄操作，這也是CAS的一個缺點所在，因為這些重試，回退等操作通常用開發者來實現。

CAS的實現並非是簡單的代碼層面控制的，而是需要硬件的支持，因此在不同的體系架構之間執行的性能差異很大。但是一個很管用的經驗法則是：在大多數處理器上，在無競爭的鎖獲取和釋放的”快速代碼路徑“上的開銷，大約是CAS開銷的兩倍。

為何CAS如此優秀

硬件加持，現代大多數處理器都從硬件層面通過一些列指令實現CompareAndSwap(比較並交換)同步原語，進而使操作系統和JVM可以直接使用這些指令實現鎖和併發的數據結構。我們可以簡單認為，CAS是將比較和交換合成是一個原子操作。

JVM對CAS的支持， 由於Java程序運行在JVM上，所以應對不同的硬件體系架構的處理則需要JVM來實現。在不支持CAS操作的硬件上，jvm將使用自旋鎖來實現。

CAS的ABA問題

cas操作讓我們減少了鎖帶來的性能損耗，同時也給我們帶來了新的麻煩-ABA問題。

在線程A讀取到x的值與執行CAS操作期間，線程B對x執行了兩次修改，x的值從100變成200，然後再從200變回100；而後在線程A執行CAS操作過程中並未發現x發生過變化，成功修改了x的值。由於x的值100 ->200->100,所以稱之為ABA的原因。

魔高一尺道高一丈，解決ABA的問題目前最常用的辦法就是給數據加上“版本號”，每次修改數據時同時改變版本號即可。

Q&A

在競爭比較激烈的情況下，CAS要進行回退，重試等操作才能得到正確的結果，那麼CAS一定比加鎖性能要高嗎？

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

2016台北國際光電週將於6月15日至17日假台北世貿南港展覽館展出，本屆在光電產業大力支持下，結合了國內知名學會、公會，和產業聯盟，齊心推動國際光電大展、平面顯示器展、LED照明展、精密光學展、太陽光電展，以及奈米科技等6展，並開闢車用光電、生醫、3D列印、前瞻學術、雷射與真空技術等6個展區，加上同期舉行之植物工廠展，光電科技不僅跨足農業、醫療、傳統產業等，而且還搭上物聯網與車用光電的跨領域列車，可看出台北國際光電週與產業正進行之蛻變。   2016 國際IoT 車用光電技術趨勢論壇於2016年6月15日-17日舉辦，結合物聯網與車用光電市場，探討未來車用市場發展。工研院資通所車在資通訊與控制系統組組長 蔣村杰表示強化行車安全為車聯網當務之急。V2X 通訊技術大約包含六個層面: 汽車對汽車 V2V、汽車對路側設備 V2R、汽車對基礎設施 V2I、汽車對行人V2P、汽車對機車 V2M、汽車對公車 V2T。其中，V2V 車間通訊技術已發展日趨成熟。工研院為全球少數公司具有完整V2X 解決方案。  

  同時提到全球車聯網發展趨勢上，在政策面上，歐美相繼立法推動車聯網應用與服務，也宣布2022年9月1日起AEB 自動緊急剎車輔助系統將列為新車標準配備之中。   並且，未來智慧車輛系統三大趨勢包含: 車聯網；智慧感測，能結合影像辨識、環境偵測、等應用並發展客製化車用積體電路 (ASIC)；先進駕駛輔助系統。  

凱銳光電 蔡家祥處長提出，物聯網應用於家庭之中，提升舒適程度；而應用於車輛之中，則是提升安全程度。智慧車載功能之中則包含安全駕駛、行車資訊彙整、車主運營效益、車上乘客資訊提供與娛樂。以車載資訊暨娛樂系統的挑戰來看，寬頻化、資安、自動駕駛等問題需要克服。當然未來，無人駕駛車時代隨之來臨!   國際富豪汽車股份有限公司 (VOLVO) 地區經理 吳廷颺提出 VOLVO 最重視駕駛安全性。在物聯網時代之下，車輛感測前方路況，提供警示或是緊急自動剎車；行人進入危險區域，提供警示或是緊急自動剎車；無人駕駛等等。時至今日，VOLVO 已正式售出200萬輛配備City Safety 自動煞車功能。   若以自動駕駛來說，VOLVO 從2009年起開始研發執行Drive Me。未來真正的自動駕駛除可判別周遭環境，甚至是駕駛者未能注意到的狀況，採用雷達、相機提供警告或是真正在危險時，可以直接執行指令，2017年將有可能提供100萬輛自動駕駛車於市。   （本文內容由授權使用）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?