引言

今天來聊聊命名相關內容。

在日常工作中，項目、類、方法、表等等等等，都需要我們起名來標識區分。好的名字讓人賞心悅目，不好的名字讓人看的想吐。

最近工作有幸寫了node、前端、php、sql、scala，也見識了公司各位前輩們的命名功底。其中不乏abc命名、拼音命名、蹩腳英文命名，更有不少從別的地方粘過來連名都不改的操作。

命名沒有對錯，只是規範一點，可以提高可讀性、可維護性。

命名原則

拼寫正確

拼寫正確是可讀的基礎。

play shift和play shit自己體會一下

清新明了，見名知意

根據要表達的內容命名，一針見血。

getNameById 根據id獲取名稱
ClassLoader 類加載器
MYSQL_USERNAME mysql用戶名 

如上幾個例子，我們一眼就知道要表達什麼，可讀性高。

使用英文字母命名

在編程中，英文還是較為主流的，最好使用單詞來命名，再不濟也是用拼音來命名。

不論是拼音或單詞，清晰表意是首要。

保持一致

在一個項目中，應該使用統一的規範來命名。

無規矩不成方圓。

合理使用動詞名詞

類名、變量名通常應使用名詞。如ClassLoader、userId

對於方法名、函數名，應包含動詞。如handleClick、generateUniqueId

命名方法

常見的命名方法有駝峰命名法、匈牙利命名法、帕斯卡命名法、中/下劃線命名法

駝峰命名法Camel-Case

駝峰命名法，又叫小駝峰命名法，如名稱所表達的意思，指混合使用大小寫字母老表示名字。

如userId、getCompanyNameById

應用很廣泛。

匈牙利命名法

基本原則是：變量名=屬性+類型+對象描述。通過名稱可以直觀的了解他的所屬、類型等信息。

是早期的命名方式，早期IDE沒有很智能的時候，這種命名是很有必要的。

如iNum，表示int類型的num

現在依舊很少有人用了。

帕斯卡命名法

又叫大駝峰命名法，就是把駝峰命名的首字母大寫了。

如ClassLoader

中/下劃線命名法

單詞全部小寫，單詞和單詞間用中劃線或下劃線分割。

如user_id、python-flask-demo

下劃線命名在數據庫中較為常見。

常量命名法

這個不是官方的方法，但是常量一般是由固定規範的。

格式：所有單詞的所有字母都是大寫，單詞之間用下戶線連接。

如APOLLO_NAMESPAC

總結

好的命名習慣是每個程序員必備的基本素養。

寫代碼時，好的命名會讓思路更加清洗，代碼寫的更加絲滑。

代碼就是程序員的形象，從命名的細節開始，讓自己更帥一些。

個人公眾號：碼農峰，定時推送行業資訊，持續發布原創技術文章，歡迎大家關注。

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

前言

最近真的是太忙忙忙忙忙了，很久沒有更新文章了。最近工作中看到了幾段關於函數式編程的代碼，但是有點費解，於是就準備總結一下函數式編程。很多東西很簡單，但是如果不總結，可能會被它的各種變體所困擾。接觸Lambda表達式已經很久了，但是也一直是處於照葫蘆畫瓢的階段，所以想自己去編寫相關代碼，也有些捉襟見肘。

1. Lambda表達式的不同形式

// 基本形式
參數 -> 主體

1.1 形式一

Runnable noArguments = () -> System.out.println("Hello World");

該形式的Lambda表達式不包含參數，使用空括號()表示沒有參數。它實現了Runnable接口，該接口也只有一個run方法，沒有桉樹，且返回類型為void。

1.2 形式二

ActionListener oneArgument = event -> System.out.println("button clicked");

該形式的Lambda表達式包含且只包含一個參數，可省略參數的符號。

1.3 形式三

Runnable multiStatement = () -> {
	System.out.print("Hello"); 
    System.out.println(" World"); 
};

Lambda表達式的主體不僅可以使一個表達式，而且也可以是一段代碼塊，使用大括號{}將代碼塊括起來。該代碼塊和普通方法遵循的規則別無二致，可以用返回或拋出異常來退出。只有以行代碼的Lambda表達式也可以使用大括號，用以明確Lambda表達式從何處開始，到哪裡結束。

1.4 形式四

BinaryOperator<Long> add = (x, y) -> x + y;

Lambda表達式也可以表示包含多個參數的方法，上面的Lambda表達式並不是將兩個数字相加，而是創建了一個函數，用來計算兩個数字相加的結果。變量add的類型時BinaryOperator ，它不是兩個数字的和，而是將兩個数字相加的那行代碼。

1.5 形式五

BinaryOperator<Long> addExplicit = (Long x, Long y) -> x + y;

到目前為止，所有Lambda表達式中的參數類型都是由編譯器推斷得出的。但有時最好也可以显示聲明參數類型，此時就需要使用小括號將參數括起來，多個參數的情況也是如此。

2. 引用值，而不是變量

如果你曾使用過匿名內部類，也許遇到過這樣的情況：需要引用它所在方法里的變量。這是，需要將變量聲明為final。

final String name = getUserName(); 
button.addActionListener(new ActionListener() {
	public void actionPerformed(ActionEvent event) { 
        System.out.println("hi " + name); 
    } 
});

將變量聲明為 final，意味着不能為其重複賦 值。同時也意味着在使用 final 變量時，實際上是在使用賦給該變量的一個特定的值。

Java 8 雖然放鬆了這一限制，可以引用非 final 變量，但是該變量在既成事實上必須是 final(意思就是你不能再次對該變量賦值)。雖然無需將變量聲明為 final，但在 Lambda 表達式中，也無法用作非終態變量。如 果堅持用作非終態變量，編譯器就會報錯。 既成事實上的 final 是指只能給該變量賦值一次。換句話說，Lambda 表達式引用的是值， 而不是變量。

例如：

String name = getUserName(); 
button.addActionListener(event -> System.out.println("hi " + name));

3. 函數接口

在 Java 里，所有方法參數都有固定的類型。假設將数字 3 作為參數傳給一個方法，則參數 的類型是 int。那麼，Lambda 表達式的類型又是什麼呢？

使用只有一個方法的接口來表示某特定方法並反覆使用，是很早就有的習慣。使用 Swing 編寫過用戶界面的人對這種方式都不陌生，這裏無需再標新立異，Lambda 表達式也使用同樣的技巧，並將這種接口稱為函數接口。

接口中單一方法的命名並不重要，只要方法簽名和 Lambda 表達式的類型匹配即可。可在函數接口中為參數起一個有意義的名字，增加代碼易讀性，便於更透徹 地理解參數的用途。

3.1 Java中重要的函數接口

接口	參數	返回類型	示例
Predicate	T	boolean	判斷是否
Consumer	T	void	輸出一個值
Function<T,R>	T	T	獲得對象的名字
Supplier	None	T	工廠方法
UnaryOperator	T	T	邏輯非（!）
BinaryOperator	(T, T)	T	求兩個數的乘積（*）

3.2 函數接口定義

定義函數接口需要使用到註解@FunctionalInterface

例如：

@FunctionalInterface
public interface MyFuncInterface {
	void print();
}

使用：

public class MyFunctionalInterfaceTest {
    public static void main(String[] args) {
        doPrint(() -> System.out.println("java"));
    }

    public static void doPrint(MyFuncInterface my) {
        System.out.println("請問你喜歡什麼編程語言？");
        my.print();
    }
}

說明：

這隻是一個很簡單的例子，有人覺得為什麼要搞這麼複雜，去定義一個接口？這個問題還是讀者在平時的工作中去感悟吧，總之，先學會怎麼用它。不至於看了別人寫的代碼都看不懂。

至於我個人的理解，可以簡單聊聊。以前寫過JavaScript，裏面有一種語法就是將自定義函數B作為參數傳遞到另外一個函數A裏面，在函數A裏面會執行你自定義的函數B邏輯，我當時就非常喜歡這種特性，因為每個人關於函數B的實現可能不一樣，亦或者場景不一樣也會導致函數B的實現不一樣。我覺得Java8的這個函數式編程就是對這一特性的補充。

4. 流

流的常用操作有很多，例如collect(toList())、map、filter、max、min等，下面介紹一下flatMap和reduce。

4.1 flatMap

flatMap 方法可用 Stream 替換值，然後將多個 Stream 連接成一個 Stream。

List<Integer> together = Stream.of(asList(1, 2), asList(3, 4)) 				 
    .flatMap(numbers -> numbers.stream())
    .collect(toList()); 
assertEquals(asList(1, 2, 3, 4), together);

調用 stream 方法，將每個列錶轉換成 Stream 對象，其餘部分由 flatMap 方法處理。 flatMap 方法的相關函數接口和 map 方法的一樣，都是 Function 接口，只是方法的返回值 限定為 Stream 類型罷了。

4.2 reduce

reduce 操作可以實現從一組值中生成一個值。對於 count、min 和 max 方 法，因為常用而被納入標準庫中。事實上，這些方法都是 reduce 操作。

如何通過 reduce 操作對 Stream 中的数字求和。以 0 作起點——一個空Stream 的求和結果，每一步都將 Stream 中的元素累加至 accumulator，遍歷至 Stream 中的 最後一個元素時，accumulator 的值就是所有元素的和。

int count = Stream.of(1, 2, 3)
    .reduce(0, (acc, element) -> acc + element); 
assertEquals(6, count);

Lambda 表達式的返回值是最新的 acc，是上一輪 acc 的值和當前元素相加的結果。reducer 的類型是前面已介紹過的 BinaryOperator。

5. Optional

reduce 方法的一個重點尚未提及：reduce 方法有兩種形式，一種如前面出現的需要有一 個初始值，另一種變式則不需要有初始值。沒有初始值的情況下，reduce 的第一步使用 Stream 中的前兩個元素。有時，reduce 操作不存在有意義的初始值，這樣做就是有意義的，此時，reduce 方法返回一個 Optional 對象。

Optional 是為核心類庫新設計的一個數據類型，用來替換 null 值。人們對原有的 null 值有很多抱怨。人們常常使用 null 值表示值不存在，Optional 對象能更好地表達這個概念。使用 null 代 表值不存在的最大問題在於 NullPointerException。一旦引用一個存儲 null 值的變量，程 序會立即崩潰。使用 Optional 對象有兩個目的：首先，Optional 對象鼓勵程序員適時檢查變量是否為空，以避免代碼缺陷；其次，它將一個類的 API 中可能為空的值文檔化，這比閱讀實現代碼要簡單很多。

下面我們舉例說明 Optional 對象的 API，從而切身體會一下它的使用方法。使用工廠方法 of，可以從某個值創建出一個 Optional 對象。Optional 對象相當於值的容器，而該值可以 通過 get 方法提取。

Optional<String> a = Optional.of("a"); 
assertEquals("a", a.get());

Optional 對象也可能為空，因此還有一個對應的工廠方法 empty，另外一個工廠方法 ofNullable 則可將一個空值轉換成 Optional 對象。下面的代碼同時展示 了第三個方法 isPresent 的用法（該方法表示一個 Optional 對象里是否有值）。

Optional emptyOptional = Optional.empty(); 
Optional alsoEmpty = Optional.ofNullable(null); assertFalse(emptyOptional.isPresent());

使用 Optional 對象的方式之一是在調用 get() 方法前，先使用 isPresent 檢查 Optional 對象是否有值。使用 orElse 方法則更簡潔，當 Optional 對象為空時，該方法提供了一個 備選值。如果計算備選值在計算上太過繁瑣，即可使用 orElseGet 方法。該方法接受一個 Supplier 對象，只有在 Optional 對象真正為空時才會調用。

assertEquals("b", emptyOptional.orElse("b")); 
assertEquals("c", emptyOptional.orElseGet(() -> "c"));

最後

實踐是檢驗真理的唯一標準，多寫代碼，多思考，你的代碼才會越來越好。

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

背景

之前做過一次uboot的升級，當時留下了一些記錄，本文摘錄其中比較有意思的兩個問題。

啟動失敗問題

問題簡述

uboot代碼中用到了一個庫，考慮到庫本身跟uboot版本沒什麼關係，就直接把舊的庫文件拷貝過來使用。結果編譯鏈接是沒問題，啟動卻會卡住。

消失的打印

為了明確卡住的位置，就去修改了庫的源碼，添加一些打印（此時還是在舊版本uboot下編譯的），結果發現卡住的位置或隨着添加打印的變化而變化，且有些打印語句，添加后未打印出來。

我決定先從這些神秘消失的打印入手。

分析下uboot中的printf實現，最底層就是寫寄存器，是一個同步的函數，也沒什麼可疑的地方。

為了確認打印不出來的時候，到底有沒有調用到printf，我決定給printf增加一個計數器，在gd結構體中，增加一個printf_count字段，初始化為0，每次打印時執行printf_count++並打印出值。

設計這個試驗，本意是確認未打印出來時是否確實也調用到了printf，但卻有了別的發現，實驗結果中printf_count值會異常變化，不是按打印順序遞增，而是會突變成很大的異常值。

printf_count是gd結構體的成員，那就是gd的問題了。進一步將uboot全局結構體gd的地址打印出來。確認了原因是gd結構體的指針變化了。

這也可以解釋部分打印消失的現象，原因是我們在gd中有另一個字段，用於控制打印等級。當gd被改動了，printf就可能解析出錯，誤以為打印等級為0而提前返回。

gd的實現

那麼好端端的，gd為什麼會被改了呢？這就要先看看gd到底是怎麼實現的了。

uboot中維護了一個全局的結構體gd。在代碼中加入

DECLARE_GLOBAL_DATA_PTR;

即可使用gd指針訪問這個全局結構體，許多地方都會藉助gd來保存傳遞信息。

進一步看看這個宏的定義

舊版本uboot:
#define DECLARE_GLOBAL_DATA_PTR        register volatile gd_t *gd asm ("r8")

新版本uboot:
#define DECLARE_GLOBAL_DATA_PTR        register volatile gd_t *gd asm ("r9")

居然不一樣，一個是將gd的值放到r8寄存器，一個是放在r9寄存器。

那麼就可以猜測到，庫是在舊版本uboot中編譯出來的，可能使用了r9，那麼放到新版本uboot中去，就會破壞r9寄存器中保存的gd值，導致一系列依賴gd的代碼不能正常工作。

驗證改動

為了求證，將庫反彙編出來，發現確實避開了r8寄存器，但使用了r9寄存器。

說明uboot在指定gd寄存器的同時，還有某種方法讓其他代碼不使用這個寄存器。

那是不是把舊uboot中的這個r8改成r9，重新編譯庫就可以了呢？試一下，還是不行。

那麼禁止其他代碼使用r8寄存器肯定就是通過別的方式實現的了。簡單粗暴地在舊版本uboot下搜索r8，去掉.c .h等類型后，很容易發現了

./arch/arm/cpu/armv7/config.mk:24:PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-floa

將-ffixed-r8修改為-ffixed-r9，重新編譯出庫，這回就可以正常工作了，打印正常，啟動正常。反彙編出來也可以看到，新編譯出來的庫用了r8沒有用r9。

當然更好的改法，是直接在新版本的uboot中編譯，這是最可靠的。

追本溯源

話說回來，為什麼兩個版本的uboot，會使用不同的寄存器呢？難道有什麼坑？

這就得去翻一下git記錄了。

commit fe1378a961e508b31b1f29a2bb08ba1dac063155
Author: Jeroen Hofstee <jeroen@myspectrum.nl>
Date:   Sat Sep 21 14:04:41 2013 +0200

    ARM: use r9 for gd
    
    To be more EABI compliant and as a preparation for building
    with clang, use the platform-specific r9 register for gd
    instead of r8.
    
    note: The FIQ is not updated since it is not used in u-boot,
    and under discussion for the time being.
    
    The following checkpatch warning is ignored:
    WARNING: Use of volatile is usually wrong: see
    Documentation/volatile-considered-harmful.txt
    
    Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
    cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

從git記錄中，也可以確認完整地將r8切換到r9，都需要做哪些修改

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 16c2e3d1e0..d0cf43ff41 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -17,7 +17,7 @@ endif
 
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
-                     -fno-common -ffixed-r8 -msoft-float
+                     -fno-common -ffixed-r9 -msoft-float
 
 # Support generic board on ARM
 __HAVE_ARCH_GENERIC_BOARD := y
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S b/arch/arm/cpu/armv7/lowlevel_init.S
index 82b2b86520..69e3053a42 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -22,11 +22,11 @@ ENTRY(lowlevel_init)
        ldr     sp, =CONFIG_SYS_INIT_SP_ADDR
        bic     sp, sp, #7 /* 8-byte alignment for ABI compliance */
 #ifdef CONFIG_SPL_BUILD
-       ldr     r8, =gdata
+       ldr     r9, =gdata
 #else
        sub     sp, #GD_SIZE
        bic     sp, sp, #7
-       mov     r8, sp
+       mov     r9, sp
 #endif
        /*
         * Save the old lr(passed in ip) and the current lr to stack
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index 79a9597419..e126436093 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -47,6 +47,6 @@ struct arch_global_data {
 
 #include <asm-generic/global_data.h>
 
-#define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r9")
 
 #endif /* __ASM_GBL_DATA_H */
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 960d12e732..ac54b9359a 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -69,7 +69,7 @@ ENTRY(_main)
        bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
        sub     sp, #GD_SIZE    /* allocate one GD above SP */
        bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
-       mov     r8, sp          /* GD is above SP */
+       mov     r9, sp          /* GD is above SP */
        mov     r0, #0
        bl      board_init_f
 
@@ -81,15 +81,15 @@ ENTRY(_main)
  * 'here' but relocated.
  */
 
-       ldr     sp, [r8, #GD_START_ADDR_SP]     /* sp = gd->start_addr_sp */
+       ldr     sp, [r9, #GD_START_ADDR_SP]     /* sp = gd->start_addr_sp */
        bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
-       ldr     r8, [r8, #GD_BD]                /* r8 = gd->bd */
-       sub     r8, r8, #GD_SIZE                /* new GD is below bd */
+       ldr     r9, [r9, #GD_BD]                /* r9 = gd->bd */
+       sub     r9, r9, #GD_SIZE                /* new GD is below bd */
 
        adr     lr, here
-       ldr     r0, [r8, #GD_RELOC_OFF]         /* r0 = gd->reloc_off */
+       ldr     r0, [r9, #GD_RELOC_OFF]         /* r0 = gd->reloc_off */
        add     lr, lr, r0
-       ldr     r0, [r8, #GD_RELOCADDR]         /* r0 = gd->relocaddr */
+       ldr     r0, [r9, #GD_RELOCADDR]         /* r0 = gd->relocaddr */
        b       relocate_code
 here:
 
@@ -111,8 +111,8 @@ clbss_l:cmp r0, r1                  /* while not at end of BSS */
        bl red_led_on
 
        /* call board_init_r(gd_t *id, ulong dest_addr) */
-       mov     r0, r8                  /* gd_t */
-       ldr     r1, [r8, #GD_RELOCADDR] /* dest_addr */
+       mov     r0, r9                  /* gd_t */
+       ldr     r1, [r9, #GD_RELOCADDR] /* dest_addr */
        /* call board_init_r */
        ldr     pc, =board_init_r       /* this is auto-relocated! */

啟動慢問題

問題簡述

填了幾個坑之後，新的uboot可以啟動到內核了，但發現啟動速度非常慢，內核啟動速度慢了接近10倍！明明是同一個內核，為什麼差異這麼大。

排查寄存器

初步排查了下設備樹配置，以及uboot跳轉內核前的一些關鍵寄存器，確實在兩個版本的uboot中有所不同，但具體去看這些不同，發現都不會影響速度，將一些驅動對齊之後寄存器差異基本就消失了。

差異的分界

那再細看，kernel的速度有差異，uboot呢？在哪個時間點之後，速度開始產生差異？

嘗試在兩個版本的uboot中插入一些操作，對比時間戳，發現兩個uboot在某個節點之後的速度確實有區別。

進一步排查，原來是在打開cache操作之後，舊uboot的速度就會比新uboot快。嘗試將舊uboot的cache關掉，則二者基本一致。嘗試將舊uboot操作cache的代碼，移植到新uboot，未發生改變。

此時可確認新uboot的開cache有問題。但覺得這個跟kernel啟動慢沒關係。因為uboot進入kernel之前都會關cache，由kernel自己去重新打開。

也就是不管是用哪份uboot，也不管uboot中是否開了cache，對kernel階段都應該沒有影響才對。

於是記錄下來uboot的這個問題，待後續修復。先繼續找kernel啟動慢的原因。（注：現在看來當時的做法是有問題的，這裏的異常這麼明顯，應該設法追蹤下去找出原因才對）

鎖定uboot

uboot的嫌疑非常大，但還不能完全確認，因為uboot之前還有一級spl。是否會是spl的問題呢？

嘗試改用新spl+舊uboot，啟動速度正常。而新spl+新uboot的啟動速度則很慢，其他因素都不變，說明問題確實出在uboot階段。

多做or少做

當時到這一步就卡住了，直接比較兩份uboot的代碼不太現實，差異太大了。

後來我就給自己提了個問題，到底新uboot是多做了某件事情，還是少做了某件事情？

換個說法，目前已知

spl --> 舊uboot --> kernel(速度快)
spl --> 新uboot --> kernel(速度快)

但到底是以下的情況A還是情況B呢？

A: spl（速度慢） --> 舊uboot(做了某個會提升速度的操作) --> kernel(速度快)
   spl（速度慢） --> 新uboot(少做了某個會提升速度的操作) --> kernel(速度慢)

B: spl（速度快） --> 舊uboot(沒做特殊操作) --> kernel(速度快)
   spl（速度快） --> 新uboot(多做了某個會限制速度的操作) --> kernel(速度慢)

為了驗證，我決定讓spl直接啟動內核，看看內核到底是快是慢。

支持過程碰到了一些小問題

1.spl沒有能力加載這麼大的kernel

解決：此時不需要kernel能完全啟動，只需要能加載啟動一段，足以體現出啟動速度是否正常即可，於是裁剪出一個非常小kernel來輔助實驗。

2.kernel需要dtb

解決：內核有一個CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE選項。選上重新編譯。編譯后再用dd將kernel和dtb拼接到一起，作為新的kernel。這樣，spl就只需要加載一個文件並跳轉過去即可。

試驗結果，spl啟動的kernel和使用新uboot啟動的kernel速度一致，均比舊uboot啟動的kernel慢。

說明，舊uboot中做了某個關鍵操作，而新uboot沒做。

找出關鍵操作

那接下來的任務就是，找出舊uboot中的這個關鍵操作了。

怎麼找呢？有了上一步的成果，我們可以使用以下方法來排查

1. spl加載kernel和舊uboot

2. spl跳轉到舊uboot，此時kernel其實已經在dram中準備好了，隨時可以啟動

3. 在舊uboot的啟動流程各個階段，嘗試直接跳轉到kernel，觀察啟動速度

4. 如果在舊uboot的A點跳轉kernel啟動慢，B點跳轉啟動快，則說明關鍵操作位於AB點之間。

方法有了，很快就鎖定到start.S，進一步在start.S中揪出了這段代碼

#if defined(CONFIG_ARM_A7)
@set SMP bit
    mrc     p15, 0, r0, c1, c0, 1
    orr        r0, r0, #(1<<6)
    mcr        p15, 0, r0, c1, c0, 1
#endif

新uboot的start.S中沒有這段代碼，嘗試在新uboot的start.S中添加此操作，速度立馬恢復正常了。

再全局搜索下，原來這個新版本uboot中，套路是在board_init中進行此項設置的，而這個平台從舊版本移植過來，就沒有設置 SMP bit, 補上即可。

SMP bit是什麼

SMP 是指對稱多處理器，看起來這個 bit 會影響多核的 cache一致性，此處沒有再深入研究。

但可以知道，對於單處理器的情況，也需要設置這個bit才能正常使用cache。

貼下arm的圖和描述：

[6]	SMP	

Signals if the Cortex-A9 processor is taking part in coherency or not.

In uniprocessor configurations, if this bit is set, then Inner Cacheable Shared is treated as Cacheable. The reset value is zero.

搜下kernel的代碼，發現也是有地方調用了的。不過這個芯片是單核的，根本就沒配置CONFIG_SMP。

#ifdef CONFIG_SMP
	ALT_SMP(mrc	p15, 0, r0, c1, c0, 1)
	ALT_UP(mov	r0, #(1 << 6))		@ fake it for UP
	tst	r0, #(1 << 6)			@ SMP/nAMP mode enabled?
	orreq	r0, r0, #(1 << 6)		@ Enable SMP/nAMP mode
	orreq	r0, r0, r10			@ Enable CPU-specific SMP bits
	mcreq	p15, 0, r0, c1, c0, 1
#endif

總結

整理出來一方面是記錄這兩個bug，另一方面也是想記錄下當時的一些操作。

畢竟同樣的bug可能以後都不會碰到了，但解bug的方法和思路卻是可以積累復用的。

blog: https://www.cnblogs.com/zqb-all/p/13172546.html
公眾號：https://sourl.cn/shT3kz

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

本文始發於個人公眾號：TechFlow，原創不易，求個關注

今天是Numpy專題第6篇文章，我們一起來看看Numpy庫當中剩餘的部分。

數組的持久化

在我們做機器學習模型的研究或者是學習的時候，在完成了訓練之後，有時候會希望能夠將相應的參數保存下來。否則的話，如果是在Notebook當中，當Notebook關閉的時候，這些值就丟失了。一般的解決方案是將我們需要的值或者是數組“持久化”，通常的做法是存儲在磁盤上。

Python當中讀寫文件稍稍有些麻煩，我們還需要創建文件句柄，然後一行行寫入，寫入完成之後需要關閉句柄。即使是用with語句，也依然不夠簡便。針對這個問題，numpy當中自帶了寫入文件的api，我們直接調用即可。

通過numpy當中save的文件是二進制格式的，所以我們是無法讀取其中內容的，即使強行打開也會是亂碼。

以二進制的形式存儲數據避免了數據類型轉化的過程，尤其是numpy底層的數據是以C++實現的，如果使用Python的文件接口的話，勢必要先轉化成Python的格式，這會帶來大量開銷。既然可以存儲，自然也可以讀取，我們可以調用numpy的load函數將numpy文件讀取進來。

要注意我們保存的時候沒有添加文件後綴，numpy會自動為我們添加後綴，但是讀取的時候必須要指定文件的全名，否則會numpy無法找到，會引發報錯。

不僅如此，numpy還支持我們同時保存多個數組進入一個文件當中。

我們使用savez來完成，在這個api當中我們傳入了a=arr，b=arr，其實是以類似字典的形式傳入的。在文件當中，numpy會將變量名和數組的值映射起來。這樣我們在讀入的時候，就可以通過變量名訪問到對應的值了。

如果要存儲的數據非常大的話，我們還可以對數據進行壓縮，我們只需要更換savez成savez_compressed即可。

線性代數

Numpy除了科學計算之外，另外一大強大的功能就是支持矩陣運算，這也是它廣為流行並且在機器學習當中大受歡迎的原因之一。我們在之前的線性代數的文章當中曾經提到過Numpy這方面的一些應用，我們今天再在這篇文章當中匯總一些常用的線性代數的接口。

點乘

說起來矩陣點乘應該是最常用的線代api了，比如在神經網絡當中，如果拋開激活函數的話，一層神經元對於當前數據的影響，其實等價於特徵矩陣點乘了一個係數矩陣。再比如在邏輯回歸當中，我們計算樣本的加權和的時候，也是通過矩陣點乘來實現的。

在Andrew的深度學習課上，他曾經做過這樣的實現，對於兩個巨大的矩陣進行矩陣相乘的運算。一次是通過Python的循環來實現，一次是通過Numpy的dot函數實現，兩者的時間開銷相差了足足上百倍。這當中的效率差距和Python語言的特性以及併發能力有關，所以在機器學習領域當中，我們總是將樣本向量化或者矩陣化，通過點乘來計算加權求和，或者是係數相乘。

在Numpy當中我們採用dot函數來計算兩個矩陣的點積，既可以寫成a.dot(b)，也可以寫成np.dot(a, b)。一般來說我更加喜歡前者，因為寫起來更加方便清晰。如果你喜歡後者也問題不大，這個只是個人喜好。

注意不要寫成*，這個符號代表兩個矩陣元素兩兩相乘，而不是進行點積運算。它等價於np當中的multiply函數。

轉置與逆矩陣

轉置我們曾經在之前的文章當中提到過，可以通過.T或者是np.transpose來完成。

Numpy中還提供了求解逆矩陣的操作，這個函數在numpy的linalg路徑下，這個路徑下實現了許多常用的線性代數函數。根據線性代數當中的知識，只有滿秩的方陣才有逆矩陣。我們可以通過numpy.linalg.det先來計算行列式來判斷，否則如果直接調用的話，對於沒有逆矩陣的矩陣會報錯。

在這個例子當中，由於矩陣b的行列式為0，說明它並不是滿秩的，所以我們求它的逆矩陣會報錯。

除了這些函數之外，linalg當中還封裝了其他一些常用的函數。比如進行qr分解的qr函數，進行奇異值分解的svd函數，求解線性方程組的solve函數等。相比之下，這些函數的使用頻率相對不高，所以就不展開一一介紹了，我們可以用到的時候再去詳細研究。

隨機

Numpy當中另外一個常用的領域就是隨機數，我們經常使用Numpy來生成各種各樣的隨機數。這一塊在Numpy當中其實也有很多的api以及很複雜的用法，同樣，我們不過多深入，挑其中比較重要也是經常使用的和大家分享一下。

隨機數的所有函數都在numpy.random這個路徑下，我們為了簡化，就不寫完整的路徑了，大家記住就好。

randn

這個函數我們經常在代碼當中看到，尤其是我們造數據的時候。它代表的是根據輸入的shape生成一批均值為0，標準差為1的正態分佈的隨機數。

要注意的是，我們傳入的shape不是一個元組，而是每一維的大小，這一點和其他地方的用法不太一樣，需要注意一下。除了正態分佈的randn之外，還有均勻分佈的uniform和Gamma分佈的gamma，卡方分佈的chisquare。

normal

normal其實也是生成正態分佈的樣本值，但不同的是，它支持我們指定樣本的均值和標準差。如果我們想要生成多個樣本，還可以在size參數當中傳入指定的shape。

randint

顧名思義，這個函數是用來生成隨機整數的。它接受傳入隨機數的上下界，最少也要傳入一個上界（默認下界是0）。

如果想要生成多個int，我們可以在size參數傳入一個shape，它會返回一個對應大小的數組，這一點和uniform用法一樣。

shuffle

shuffle的功能是對一個數組進行亂序，返回亂序之後的結果。一般用在機器學習當中，如果存在樣本聚集的情況，我們一般會使用shuffle進行亂序，避免模型受到樣本分佈的影響。

shuffle是一個inplace的方法，它會在原本值上進行改動，而不會返回一個新值。

choice

這也是一個非常常用的api，它可以在數據當中抽取指定條數據。

但是它只支持一維的數組，一般用在批量訓練的時候，我們通過choice採樣出樣本的下標，再通過數組索引去找到這些樣本的值。比如這樣：

總結

今天我們一起研究了Numpy中數據持久化、線性代數、隨機數相關api的使用方法，由於篇幅的限制，我們只是選擇了其中比較常用，或者是比較重要的用法，還存在一些較為冷門的api和用法，大家感興趣的可以自行研究一下，一般來說文章當中提到的用法已經足夠了。

今天這篇是Numpy專題的最後一篇了，如果你堅持看完本專題所有的文章，那麼相信你對於Numpy包一定有了一個深入的理解和認識了，給自己鼓鼓掌吧。之後周四會開啟Pandas專題，敬請期待哦。

如果喜歡本文，可以的話，請點個關注，給我一點鼓勵，也方便獲取更多文章。

本文使用 mdnice 排版

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

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

目錄

• 多線程需要解決的問題
  • 線程之間的通信
  • 線程之間的同步
• Java內存模型
  • 內存間的交互操作
  • 指令屏障
  • happens-before規則
• 指令重排序
  • 從源程序到字節指令的重排序
  • as-if-serial語義
  • 程序順序規則
• 順序一致性模型
  • 順序一致性模型特性
  • 順序一致性模型特性
  • 當程序未正確同步會發生什麼
• 參考資料

多線程需要解決的問題

在多線程編程中，線程之間如何通信和同步是一個必須解決的問題：

線程之間的通信:

線程之間有兩種通信的方式：消息傳遞和共享內存

• 共享內存：線程之間共享程序的公共狀態，通過讀——寫修改公共狀態進行隱式通信。如上面代碼中的num和Lock可以被理解為公共狀態
• 消息傳遞：線程之間沒有公共狀態，必須通過發送消息來進行显示通信
  在java中，線程是通過共享內存來完成線程之間的通信

線程之間的同步：

同步指程序中永固空值不同線程間的操作發生的相對順序的機制

• 共享內存：同步是显示進行的，程序員需要指定某個方法或者某段代碼需要在線程之間互斥執行。如上面代碼中的Lock加鎖和解鎖之間的代碼塊，或者被synchronized包圍的代碼塊
• 消息傳遞：同步是隱式執行的，因為消息的發送必然發生在消息的接收之前，例如使用Objetc#notify()，喚醒的線程接收信號一定在發送喚醒信號的發送之後。

Java內存模型

在java中，所有的實例域，靜態域、數組都被存儲在堆空間當中，堆內存在線程之間共享。

所有的局部變量，方法定義參數和異常處理器參數不會被線程共享，在每個線程棧中獨享，他們不會存在可見性和線程安全問題。

從Java線程模型(JMM)的角度來看,線程之間的共享變量存儲在主內存當中，每個線程擁有一個私有的本地內存(工作內存)本地內存存儲了該線程讀——寫共享的變量的副本。
JMM只是一個抽象的概念，在現實中並不存在，其中所有的存儲區域都在堆內存當中。JMM的模型圖如下圖所示：

而java線程對於共享變量的操作都是對於本地內存（工作內存）中的副本的操作，並沒有對共享內存中原始的共享變量進行操作；

以線程1和線程2為例，假設線程1修改了共享變量，那麼他們之間需要通信就需要兩個步驟：

1. 線程1本地內存中修改過的共享變量的副本同步到共享內存中去
2. 線程2從共享內存中讀取被線程1更新過的共享變量
   這樣才能完成線程1的修改對線程2的可見。

內存間的交互操作

為了完成這一線程之間的通信，JMM為內存間的交互操作定義了8個原子操作，如下錶：

操作	作用域	說明
lock(鎖定)	共享內存中的變量	把一個變量標識為一條線程獨佔的狀態
unlock(解鎖)	共享內存中的變量	把一個處於鎖定的變量釋放出來，釋放后其他線程可以進行訪問
read(讀取)	共享內存中的變量	把一個變量的值從共享內存傳輸到線程的工作內存。供隨後的load操作使用
load(載入)	工作內存	把read操作從共享內存中得到的變量值放入工作內存的變量副本當中
use(使用)	工作內存	把工作內存中的一個變量值傳遞給執行引擎
assign(賦值)	工作內存	把一個從執行引擎接受到的值賦值給工作內存的變量
store(存儲)	作用於工作內存	把一個工作內存中的變量傳遞給共享內存，供後續的write使用
write(寫入)	共享內存中的變量	把store操作從工作內存中得到的變量的值放入主內存

JMM規定JVM四線時必須保證上述8個原子操作是不可再分割的，同時必須滿足以下的規則：

1. 不允許read和load、store和write操作之一單獨出現，即不允許只從共享內存讀取但工作內存不接受，或者工作捏村發起回寫但是共享內存不接收
2. 不允許一個線程捨棄assign操作，即當一個線程修改了變量后必須寫回工作內存和共享內存
3. 不允許一個線程將未修改的變量值寫回共享內存
4. 變量只能從共享內存中誕生，不允許線程直接使用未初始化的變量
5. 一個變量同一時刻只能由一個線程對其執行lock操作，但是一個變量可以被同一個線程重複執行多次lock，但是需要相同次數的unlock
6. 如果對一個變量執行lock操作，那麼會清空工作內存中此變量的值，在執行引擎使用這個變量之前需要重新執行load和assign
7. 不允許unlock一個沒有被鎖定的變量，也不允許unlock一個其他線程lock的變量
8. 對一個變量unlock之前必須把此變量同步回主存當中。

對long和double的特殊操作
在一些32位的處理器上，如果要求對64位的long和double的寫具有原子性，會有較大的開銷，為了照固這種情況，
java語言規範鼓勵但不要求虛擬機對64位的long和double型變量的寫操作具有原子性，當JVM在這種處理器上運行時，
可能會把64位的long和double拆分成兩次32位的寫

指令屏障

為了保證內存的可見性，JMM的編譯器會禁止特定類型的編譯器重新排序；對於處理器的重新排序，
JMM會要求編譯器在生成指令序列時插入特定類型的的內存屏障指令，通過內存屏障指令巾紙特定類型的處理器重新排序

JMM規定了四種內存屏障，具體如下：

屏障類型	指令示例	說明
LoadLoad Barriers	Load1;LoadLoad;Load2	確保Load1的數據先於Load2以及所有後續裝在指令的裝載
StoreStore Barries	Store1;StoreStore;Store2	確保Store1數據對於其他處理器可見（刷新到內存）先於Store2及後續存儲指令的存儲
LoadStore Barriers	Load1;LoadStore;Store2	確保Load1的裝載先於Store2及後續所有的存儲指令
StoreLoad Barrier	Store1;StoreLoad;Load2	確保Store1的存儲指令先於Load1以及後續所所有的加載指令

StoreLoad是一個“萬能”的內存屏障，他同時具有其他三個內存屏障的效果，現代的處理器大都支持該屏障（其他的內存屏障不一定支持），
但是執行這個內存屏障的開銷很昂貴，因為需要將處理器緩衝區所有的數據刷回內存中。

happens-before規則

在JSR-133種內存模型種引入了happens-before規則來闡述操作之間的內存可見性。在JVM種如果一個操作的結果過需要對另一個操作可見，
那麼兩個操作之間必然要存在happens-bsfore關係：

• 程序順序規則：一個線程中的個每個操作，happens-before於該線程的後續所有操作
• 監視器鎖規則：對於一個鎖的解鎖，happens-before於隨後對於這個鎖的加鎖
• volatitle變量規則：對於一個volatile的寫，happens-before於認意後續對這個volatile域的讀
• 線程啟動原則：對線程的start()操作先行發生於線程內的任何操作
• 線程終止原則：線程中的所有操作先行發生於檢測到線程終止，可以通過Thread.join()、Thread.isAlive()的返回值檢測線程是否已經終止
• 線程終端原則：對線程的interrupt()的調用先行發生於線程的代碼中檢測到中斷事件的發生，可以通過Thread.interrupted()方法檢測是否發生中斷
• 對象終結原則：一個對象的初始化完成（構造方法執行結束）先行發生於它的finalize()方法的開始。
• 傳遞性：如果A happens-before B B happends-beforeC，那麼A happends-before C

指令重排序

從源程序到字節指令的重排序

眾所周知，JVM執行的是字節碼，Java源代碼需要先編譯成字節碼程序才能在Java虛擬機中運行，但是考慮下面的程序;

int a = 1;
int b = 1;

在這段代碼中，a和b沒有任何的相互依賴關係，因此完全可以先對b初始化賦值，再對a變量初始化賦值；

事實上，為了提高性能，編譯器和處理器通常會對指令做重新排序。重排序分為3種：

1. 編譯器優化的重排序。編譯器在不改變單線程的程序語義的前提下，可以安排字語句的執行順序。編譯器的對象是語句，不是字節碼，
   但是反應的結果就是編譯后的字節碼和寫的語句順序不一致。
2. 執行級并行的重排序。現代處理器採用了并行技術，來將多條指令重疊執行。如果不存在數據依賴性，處理器可以改變語句對應機器指令的執行順序。
3. 內存系統的重排序，由於處理器使用了緩存和讀/寫緩衝區，這使得加載和存儲操作看上去可能是在亂序執行。

數據依賴性：如果兩個操作訪問同一個變量，且兩個操作有一個是寫操作，則這兩個操作存在數據依賴性，改變這兩個操作的執行順序，就會改變執行結果。

儘管指令重排序會提高代碼的執行效率，但是卻為多線程編程帶來了問題，多線程操作共享變量需要一定程度上遵循代碼的編寫順序，
也需要將修改的共享數據存儲到共享內存中，不按照代碼順序執行可能會導致多線程程序出現內存可見性的問題，那又如何實現呢？

as-if-serial語義

as-if-serial語義：不論程序怎樣進行重排序，(單線程)程序的執行結果不能被改變。編譯器、runtime和處理器都必須支持as-if-serial語義。

程序順序規則

假設存在以下happens-before程序規則：

    1) A happens-before B
    2) B happens-before C
    3) A happens-before C

儘管這裏存在A happens-before B這一關係，但是JMM並不要求A一定要在B之前執行，僅僅要求A的執行結果對B可見。
即JMM僅要求前一個操作的結果對於后一個操作可見，並且前一個操作按照順序排在後一個操作之前。
但是若前一個操作放在後一個操作之後執行並不影響執行結果，則JMM認為這並不違法，JMM允許這種重排序。

順序一致性模型

在一個線程中寫一個變量，在另一個線程中同時讀取這個變量，讀和寫沒有通過排序來同步來排序，就會引發數據競爭。

數據競爭的核心原因是程序未正確同步。如果一個多線程程序是正確同步的，這個程序將是一個沒有數據競爭的程序。

順序一致性模型只是一個參考模型。

順序一致性模型特性

• 一個線程中所有的操作必須按照程序的順序來執行。
• 不管線程是否同步，所有的線程都只能看到一個單一的執行順序。

在順序一致性模型中每個曹祖都必須原子執行且立刻對所有線程可見。

當程序未正確同步會發生什麼

當線程未正確同步時，JMM只提供最小的安全性，當讀取到一個值時，這個值要麼是之前寫入的值，要麼是默認值。
JMM保證線程的操作不會無中生有。為了保證這一特點，JMM在分配對象時，首先會對內存空間清0，然後才在上面分配對象。

未同步的程序在JMM種執行時，整體上是無序的，執行結果也無法預知。位同步程序子兩個模型中執行特點有如下幾個差異：

• 順序一致性模型保證單線程內的操作會按照程序的順序執行，而JMM不保證單線程內的操作會按照程序的順序執行
• 順序一致性模型保證所有線程只能看到一致的操作執行順序，而JMM不保證所有線程能看到一致的操作執行順序
• JMM不保證對64位的long和double型變量具有寫操作的原子性，而順序一致性模型保證對所有的內存的讀/寫操作都具有原子性

參考資料

java併發編程的藝術-方騰飛，魏鵬，程曉明著

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

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

可複製集 replica set

概念圖

可複製集需要至少3個以上的mongodb節點，其中有一個主節點promary,其餘的為副本節點secondary

可複製集有三個角色：

• 主要成員（Primary）：主要接收所有寫操作。就是主節點。
• 副本成員（Secondary）：從主節點通過複製操作以維護相同的數據集，即備份數據，不可寫操作，但可以讀操作（但需要配置）。是默認的一種從節點類型。
• 仲裁者（Arbiter）：不保留任何數據的副本，只具有投票選舉作用。當然也可以將仲裁服務器維護為副本集的一部分，即副本成員同時也可以是仲裁者。也是一種從節點類型。

關於仲裁者:
如果主節點+副本節點是偶數推薦添加仲裁者，如果主節點+ 副本節點是奇數可以不添加仲裁者。仲裁者將永遠是仲裁者，而主要人員可能會退出並成為次要人員，而次要人員可能成為選舉期間的主要人員。

為什麼要用可複製集？它有什麼重要性？

1. 避免數據丟失,保障數據安全,提高系統安全性；
   （最少3節點,最大50節點）
2. 自動化災備機制,主節點宕機后通過選舉產生新主機；提高系統健壯性；
   （7個選舉節點上限）
3. 讀寫分離,負載均衡,提高系統性能；

搭建

準備三個mongodb節點

正準備三個mongodb節點,我們先搭建一個主節點，2個副本節點的模式
修改配置mongo.conf

• 第一個

systemLog:
  #MongoDB發送所有日誌輸出的目標指定為文件 
  destination: file
  #mongod或mongos應向其發送所有診斷日誌記錄信息的日誌文件的路徑 
  path: "/home/amber/mongodb/mongodb-001/log/mongod.log" 
  #當mongos或mongod實例重新啟動時，mongos或mongod會將新條目附加到現有日誌文件的末尾。 
  logAppend: true
storage: 
  #mongod實例存儲其數據的目錄。storage.dbPath設置僅適用於mongod。 
  dbPath: "/home/amber/mongodb/mongodb-001/data/db" 
  journal:
    #啟用或禁用持久性日誌以確保數據文件保持有效和可恢復。 
    enabled: true
processManagement:
  #啟用在後台運行mongos或mongod進程的守護進程模式。 
  fork: true 
  #指定用於保存mongos或mongod進程的進程ID的文件位置，其中mongos或mongod將寫入其PID 
  pidFilePath: "/home/amber/mongodb/mongodb-001/log/mongod.pid" 
net:
  #服務實例綁定所有IP，有副作用，副本集初始化的時候，節點名字會自動設置為本地域名，而不是ip 
  #bindIpAll: true 
  #服務實例綁定的IP 
  bindIp: 0.0.0.0
  #bindIp 
  #綁定的端口 
  port: 27017
replication: 
  #副本集的名稱 
  replSetName: myrs

• 第二個第三個配置
  把上述文件中的mongodb-001換成mongodb-002``mongodb-003
  端口分別換成27018 27019

然後分別在mongodb-00X的根目錄下執行啟動命令

./bin/mongod -f ./conf/mongod.conf

檢查進程

ps -ef|grep mongod

設置主節點

進入27017的那個mongod的客戶端，並且執行

rs.initiate({
      _id: "myrs", //  需要和replSetName的名稱一致
      version: 1,
      members: [{ _id: 0, host : "192.168.xx.xx:27017" }]});

或者

rs.initiate({}) 

執行結果

提示：
1）“ok”的值為1，說明創建成功。
2）命令行提示符發生變化，變成了一個從節點角色，此時默認不能讀寫。稍等片刻，回車，變成主節  點。

配置副本節點

再27017的mongod客戶端，也就是主節點上執行192.168.xx.xx:27018是副本節點的ip和端口

rs.add("192.168.xx.xx:27018")
rs.add("192.168.xx.xx:27019")

使用

rs.status()

就可以看到members會有三個節點了

測試

再主節點插入一條數據

use article;
db.comment.insert({name: "amber"})

再從節點查看，結果

這是因為需要再從節點再次進行

rs.slaveok() // 確認當前節點是副本節點
db.comment.find(); // 查看當前數據

可以看到已經有數據了，這樣一主二從的可複製成功了

如果關閉主節點，在從節點執行rs.status();
可以看到原來的主節點的health變成了0

27018變成了新的主節點

主節點的選舉原則

MongoDB在副本集中，主節點選舉的觸發條件：
1） 主節點故障
2） 主節點網絡不可達（默認心跳信息為10秒）
3） 人工干預（rs.stepDown(600)）

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

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!