技术专栏 第572页

整体看来，此版本在兼容性方面没有特别大的变化。因为 TypeScript 团队表示新版本继续使用与过去版本相似的版本控制模型，可将 4.0 视作 3.9 的延续升级版本。

而且他们也一直在追求不牺牲主要灵活性的情况下，提供一个最大限度减少 breaking changes 的升级路径。

如果你还不熟悉 TypeScript，这里简单介绍一下：它是一种在 JavaScript 之上通过添加静态类型语法来构建的语言。它的基本理念是，记下值的类型以及它们的使用位置后，可以使用 TypeScript 对代码进行类型检查，并在运行代码之前（甚至在保存文件之前）告诉你代码错误的相关信息。然后，你可以使用 TypeScript 编译器从代码中剥离类型，并为你提供可在任何地方运行的简洁易读的 JavaScript 代码。除了类型检查之外，TypeScript还使用静态类型来支持强大的编辑器工具，例如自动完成、代码导航、重构等。实际上，如果你在 Visual Studio Code 或 Visual Studio 这样的编辑器中使用过 JavaScript，那么你已经用上了类型和 TypeScript 带来的体验。

TypeScript 是当今许多人使用的 JavaScript 技术栈的核心部分。在 npm 上，TypeScript 在 7 月首次实现了超过 5000 万的月下载量！尽管我们知道它总有增长和改进的余地，但很明显，大多数使用 TypeScript 编码的开发人员确实很喜欢它。StackOverflow 的最新开发人员调查将 TypeScript 列为第二受欢迎的语言。在最新的 JS 现状调查中，使用 TypeScript 的开发人员中有大约 89% 表示会再次使用它。

4.0 版本的主要更新内容如下：

• 可变参数元组类型
• 标记的元组元素
• 构造函数的类属性推断
• 短路分配运算符
• catch 子句中的unknown
• 定制 JSX 工厂
• 带--noEmitOnError参数build模式下的速度提升
• --incremental with --noEmit
• 编辑器改进
  • 转换为可选链接
  • 支持/** @deprecated */
  • 启动时的部分编辑模式
  • 更智能的自动导入
• Breaking Changes

构造函数的类属性推断

当 noImplicitAny 被启用时，TypeScript 4.0 现在可以使用控制流分(control flow analysis)析来确定类中的属性类型。

class Square {
    // Previously: implicit any!
    // Now: inferred to `number`!
    area;
    sideLength;


    constructor(sideLength: number) {
        this.sideLength = sideLength;
        this.area = sideLength ** 2;
    }
}

如果并非将构造函数的所有路径都分配给实例成员，则该属性可能被视为undefined。

class Square {
    sideLength;


    constructor(sideLength: number) {
        if (Math.random()) {
            this.sideLength = sideLength;
        }
    }


    get area() {
        return this.sideLength ** 2;
        //     ~~~~~~~~~~~~~~~
        // error! Object is possibly 'undefined'.
    }
}

在更清楚的情况下（例如具有某种initialize方法），如果位于strictPropertyInitialization中，可能会需要显式类型注释以及定值赋值断言(!)

class Square {
    // definite assignment assertion
    //        v
    sideLength!: number;
    //         ^^^^^^^^
    // type annotation


    constructor(sideLength: number) {
        this.initialize(sideLength)
    }


    initialize(sideLength: number) {
        this.sideLength = sideLength;
    }


    get area() {
        return this.sideLength ** 2;
    }
}

短路分配运算符

JavaScript 和其他很多语言都支持复合赋值运算符。复合赋值运算符将一个运算符应用到两个参数上，然后将结果赋值到左边。如下：

/ Addition
// a = a + b
a += b;


// Subtraction
// a = a - b
a -= b;


// Multiplication
// a = a * b
a *= b;


// Division
// a = a / b
a /= b;


// Exponentiation
// a = a ** b
a **= b;


// Left Bit Shift
// a = a << b
a <<= b;

JavaScript 中的许多运算符都有一个对应的赋值运算符，但有三个例外：逻辑和(&&)、逻辑或(||)，以及空值合并(??)。

TypeScript 4.0 为上述三个运算符增加了对应的赋值运算符支持：

let values: string[];


// Before
(values ?? (values = [])).push("hello");


// After
(values ??= []).push("hello");
a ||= b;


// actually equivalent to


a || (a = b);

以上就是W3Cschool编程狮关于 TypeScript 4.0 发布，有什么新的关注点？的相关介绍了，希望对大家有所帮助。

在长时间的编程开发中，你肯定见过或者使用过下面这段代码：

with open("test.txt", "r", encoding="utf-8") as f:
    s = f.readlines()

有些人会知道这么写的原因，但是更多的人不知道原因。只是觉得别人都这么写，那我也跟着写。

同时，很多知道原因的人也只是知其然而不知其所以然：with 语句可以替我们自动关闭打开的文件对象。但是这是通过什么机制办到的呢？

1. with和异常处理

我们知道，如果不使用with语句的话，正常地读写一个文件应该经过这些过程：打开文件、操作文件、关闭文件。表达为 Python 代码如下：

f = open("test.txt", "r", encoding="utf-8")
s = f.readlines()
f.close()

在正常情况下，这样写看起来也没啥问题。

接下来我们就人为制造一点“意外”：把打开文件对象时指定的模式由“r”改为“w”。

f = open("test.txt", "w", encoding="utf-8")
s = f.readlines()
f.close()

此时，当程序执行到第2行读取文件内容时，就会抛出错误：

Traceback (most recent call last):
  File "test_with.py", line 2, in <module>
    s = f.readlines()
io.UnsupportedOperation: not readable

然后……一个可怕的情况就发生了。

Python 产生未处理的异常从而退出了，导致第2行之后的代码尚未执行，因此f.close()也就再也没有机会执行。一个孤魂野鬼般打开的文件对象就这样一个人漂泊在内存的汪洋大海中，没有人知道他是谁、他从哪儿来、他要去哪儿。

就这样，每当抛出一次异常，就会产生这么一个流浪对象。久而久之，内存的汪洋大海也就顺理成章被改造成了流浪者的乐土，其他人想来压根儿没门儿。

追根究底，我们发现导致这个问题的关键在于“打开-操作-关闭”文件这个流水操作中，存在抛出异常的可能。

所以我们想到了使用 Python 为我们提供的大杀器，来对付这些异常：try-catch。

用异常处理改造一下前面的代码：

try:
    f = open("test.txt", "a", encoding="utf-8")
    s = f.readlines()
except:
    print("出现异常")
finally:
    f.close()

这样一来，通过附加的finally语句，无论文件操作是否抛出异常，都能够保证打开的文件被关闭。从而避免了不断占用资源导致资源泄露的问题。

实际上，with 语句正是为我们提供了一种try-catch-finally的封装。

编程时，看似只是随随便便的一个 with ，其实已经暗地里确保了类似于上面代码的异常处理机制。

2. 上下文管理器

with 要生效，需要作用于一个上下文管理器——

打住，到底什么是上下文管理器呢？

长话短说，就是实现了__enter__和__exit__方法的对象。

在进入一个运行时上下文前，会先加载这两个方法以备使用。进入这个运行时上下文时，调用__enter__方法；退出该上下文前，则会调用__exit__方法。

这里的“运行时上下文”，可以简单地理解为一个提供了某些特殊配置的代码作用域。

当我们使用with open("test.txt", "r", encoding="utf-8") as f这句代码时，Python首先对open("test.txt", "r", encoding="utf-8")求值，得到一个上下文管理器。

这里有一点特殊的是，Python中文件对象本身就是一个上下文管理器，因此我们可以使用open函数作为求值的表达式。

随后调用__enter__方法，返回的对象绑定到我们指定的标识符f上。文件对象的__enter__返回文件对象自身，因此这句代码就是将打开的“test.txt”文件对象绑定到了标识符f上。

紧跟着执行 with 语句块中的内容。

最后调用__exit__，退出 with 语句块。

根据上面的内容，我们也可以自行构造一个上下文管理器（注意，两个特征方法的参数要与协议一致）：

class testContextManager:
    def __enter__(self):
        print("进入运行时上下文，调用__enter__方法")


    def __exit__(self, exc_type, exc_value, traceback):
        print("退出运行时上下文，调用__exit__方法")




with testContextManager() as o:
    pass

输出结果：

进入运行时上下文，调用__enter__方法
退出运行时上下文，调用__exit__方法

with 语句之所以能够替代繁琐的异常处理语句，正是由于上下文管理器遵循协议实现了__enter__和__exit__方法，而with语句又确保了发生异常时能够执行完__exit__方法，再退出相关运行时上下文。

在这个方法中，我们就可以完成一些必要的清理工作。

总结

本文我们讲解了 with 语句的内部逻辑，尝试实现了一个自定义的上下文管理器。相信大家对于 with 的作用方式有了更深刻的领会。

with 语句不仅仅可以用于读写文件，还可以用于锁的自动获取和释放、全局状态的保存和恢复等。更多的实用方式留待大家探索。

文章来源：公众号–Python技术 作者：派森酱

以上就是W3Cschool编程狮关于 你只知道with，那with该with who呢？的相关介绍了，希望对大家有所帮助。

从事编程这么久了，或多或少都会用的一些库。今天给大家推荐5个好用的 Vue.js 库

1.Click Off to Close

有的时候，我们需要在用户点击元素之外的时候触发一个事件。最常见的用例是当你想通过点击关闭一个下拉框或对话框时。这是一个必不可少的包，几乎在我构建的每个应用中都会用到。

首选：vue-clickaway

我通常会将它安装在 main.js 中，以便在我的应用程序中使用。如果你只在一个或两个页面上使用它，你可能会想单独导入它。

如果你真的单独导入，请记住，指令需要在指令下暴露。

 directives: { onClickaway }

而不是组件：

 components: { onClickaway }

使其全局可用（在 main.js 中）：

import { directive as onClickaway } from 'vue-clickaway'
Vue.directive('on-clickaway', onClickaway)

在模板中：

想象一下，我有一个完整的选择框，其中包含 li 元素列表（此处未显示）。上面的按钮用于触发我的自定义选择框项目列表，当我在该元素外点击时，会触发一个关闭选项列表的方法。这比强迫用户始终单击元素右上角处的“X”按钮要好得多。我们只需将以下内容添加到按钮即可获得此功能： v-on-clickaway = “closeMethodName”。

注意：你应该总是在 close 方法中使用 vue-clickaway ，而不是 toggle 方法。我的意思是这个方法连接到 v-on-clickaway 应该是这样的：

closeMethod() {
  this.showSomething = false
}

而不是这样：

toggleMethod() {
  this.showSomething = !this.showSomething
}

如果你使用了 toggle 方法，那么每当你在该元素外点击时，无论你点击什么，它都会打开，然后一遍遍地关闭该元素。这很可能不是你想要的结果，所以请记住使用 close 方法来防止这种情况发生。

2.Toasts (Notification Bar)

首选：vue-toastification

你有很多toast和类似通知的选择，但我是Maronato的vue-toastification的忠实粉丝。它提供了大量的选项来覆盖你的大部分边界情况，而且样式和动画导致了出色的用户体验，远远超过其他软件包。

Vue-toastification提供了几种在其文档中使用它的方法。你可以在组件级别，全局级别甚至在Vuex内执行此操作，如果你希望根据状态或与服务器相关的操作显示toasts。

全局使用（在 main.js 中）：

import Toast from 'vue-toastification'
// Toast styles
import 'vue-toastification/dist/index.css'
Vue.use(Toast, {
  transition: 'Vue-Toastification__bounce',
  maxToasts: 3,
  newestOnTop: true,
  position: 'top-right',
  timeout: 2000,
  closeOnClick: true,
  pauseOnFocusLoss: true,
  pauseOnHover: false,
  draggable: true,
  draggablePercent: 0.7,
  showCloseButtonOnHover: false,
  hideProgressBar: true,
  closeButton: 'button',
  icon: true,
  rtl: false
})

你可以在每个组件中单独控制样式，但在上面的案例中，我通过将它导入 main.js，然后在那里设置我想使用的选项，使它在我的应用程序中到处可用，这使我不必每次都编写相同的选项属性。Vue-toastification有一个很好的在线演示，在这里你可以看到每个选项属性的结果，只需要复制粘贴你想要的选项，就像我上面做的那样。

/ 选项1：在组件（模板）中使用Toast /

<button @click="showToast">Show toast</button> 

/ 选项2：在Vuex action中发现错误（或成功）时调用Toast /

你只需将 .error 改为 .success，.info，.warning 即可更改所需的 Toast 类型，也可以将其完全删除以作为默认的 Toast 通知。

Toasts 可以让你根据实时状态的变化或者发生了不可预见的错误来显示消息，这大大改善了用户的体验。Toasts 提供了比模态或丑陋的提示框更好的视觉指示，例如，用户必须提供一个额外的点击来关闭。用户会很感激你给他们一个视觉上的提示，让他们知道出了什么问题，防止他们盯着屏幕茫然地等待一些永远不会发生的事情。确认他们执行的操作是否成功完成也很有用。

3.Tables

首选：vue-good-table

表格是许多Web应用程序的重要组成部分，选择错误的表格会让你陷入无尽的痛苦之中。尝试了很长的包选项列表后，我相信vue-good-table将解决你大部分的表需求。它不仅仅是为了好玩才叫“good-table”。它真的很好，提供了更多的选择和功能，超出了你的能力范围。

在以下情况下，我将 :rows 数据绑定到名为 getOrderHistory 的Vuex getter。

在本地 data() 中定义我的列：

label 是显示的列标题，而 field 是我在Vuex getter中绑定的数据。

在上图中，我还使用了vue-good-table的一些自定义选项，比如设置我的日期的输入和输出格式(这让我可以把服务器提供的一个很长的时间戳改成对我的用户来说更易读的东西)。我还使用 formatFn来格式化我的价格，调用了一个我命名为 toLocale 的单独方法，然后我通过绑定 tdClass 到我在 local <style> 中设置的类来定制每个单元格的外观。Vue-good-table确实内置了无穷的可定制性，他们已经覆盖了非常广泛的边缘案例。

Vue-good-table还可以与自定义模板配合使用，因此你可以轻松地将按钮，选择框或您喜欢的其他任何东西注入到表格的单元格中。为此，你只需使用 v-if 定义应将其注入的位置。

要添加另一个自定义列，只需在你的 v-if 标签后面添加一个 v-else-if（在上面的例子中是一个跨度），然后在那里添加第二个自定义模板的逻辑。无论你需要什么，vue-good-table都能满足你的需求。

4.Date Picker

首选：vue2-datepicker

啊，日期选择器，这是许多应用程序的重要组成部分。在这个列表中，日期选择器的选择比其他任何东西都多，但Mengxiong打造的vue2-datepicker是我不断回归的一个选择。它的风格简单，提供了广泛的选择日期和日期范围的选项，并被包装在一个光滑和用户友好的UI中。它甚至支持i18n语言和日期格式的本地化。

注意：尽管包名为vue2-datepicker，但将这个包(或这里列出的其他包)添加到Vue 3.0应用程序中应该没有问题。

在组件或视图中导入，使其可以使用。

import DatePicker from 'vue2-datepicker';
// styles
import 'vue2-datepicker/index.css';

在模板中：

在这里，我使用的是 range 选项，允许用户选择日期范围，并将用户输入的日期 v-model 以一个名为 dateRange 的数据值绑定。然后，vue-good-table（如下）使用 dateRange 对我的表的结果进行排序。我还使用事件选项 @clear 和 @input 来触发重置表（resetList）或发送服务器请求表数据（searchDate）的方法。Vue2-datepicker提供了更多的选项和事件，以方便你的使用，但这些是我发现自己最经常使用的。

5.User Ratings

首选：vue-star-rating

虽然你可能不会在每个项目中都使用这个功能，但对于任何需要用户评级元素的网站（比如Amazon或Rotten Tomatoes），vue-star-rating是我的首选。自己创建看似是一件微不足道的事情，但当你进入细节后，星级评定很快就会变得比你预期的要复杂。如果需要特殊功能，它可以让你使用自定义SVG形状，并且可以轻松自定义大小，间距和颜色。

通过这些选项，可以很容易地将用户选择的评级 v-model 绑定到任何你想使用的地方，你可以通过一个prop将评级设置为可更改或只读。

如果你发现需要更多选择，请查看创建者的扩展软件包vue-rate-it。

在模板中（带有选项）：

将其导入到组件或视图中：

文章来源：www.toutiao.com/a6865327554656469508/ 作者：杭州程序员小张

以上就是W3Cschool编程狮关于 推荐5个很好用的Vue.js库 的相关介绍了，希望对大家有所帮助。

重写了 equals ，还要重写 hashCode ？这不仅仅是一道面试题，而且是关系到我们的代码是否健壮和正确的问题。本篇文章，带大家从底层来分析一下hashcode方法重写的意义以及如何实现。

回顾equals方法

我们先回顾一下 Object的equals方法 实现，并简单汇总一下使用equals方法的规律。

public boolean equals(Object obj) {
    return (this == obj);
}

通过上面Object的源代码，可以得出一个结论：如果一个类未重写equals方法，那么本质上通过“==”和equals方法比较的效果是一样的，都是比较两个对象的的内存地址。

前面两篇文章讲到String和Integer在比较时的区别，关键点也是它们对equals方法的实现。

面试时总结一下就是：默认情况下，从Object类继承的equals方法与“==”完全等价，比较的都是对象的内存地址。但我们可以重写equals方法，使其按照需要进行比较，如String类重写了equals方法，比较的是字符的序列，而不再是内存地址。

与hashCode方法的关系

那么equals方法与hashCode方法又有什么关系呢？我们来看Object上equals方法的一段注释。

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

大致意思是：当重写equals方法后有必要将hashCode方法也重写，这样做才能保证不违背hashCode方法中“相同对象必须有相同哈希值”的约定。

此处只是提醒了我们重写hashCode方法的必要性，那其中提到的hashCode方法设计约定又是什么呢？相关的内容定义在hashCode方法的注解部分。

hashCode方法约定

关于hashCode方法的约定原文比较多，大家直接看源码即可看到，这里汇总一下，共三条：

（1）如果对象在使用equals方法中进行比较的参数没有修改，那么多次调用一个对象的hashCode()方法返回的哈希值应该是相同的。

（2）如果两个对象通过equals方法比较是相等的，那么要求这两个对象的hashCode方法返回的值也应该是相等的。

（3）如果两个对象通过equals方法比较是不同的，那么也不要求这两个对象的hashCode方法返回的值是不相同的。但是我们应该知道对于不同对象产生不同的哈希值对于哈希表(HashMap等)能够提高性能。

其实，看到这里我们了解了hashCode的实现规约，但还是不清楚为什么实现equals方法需要重写hashCode方法。但我们可以得出一条规律：hashCode方法实际上必须要完成的一件事情就是，为equals方法认定为相同的对象返回相同的哈希值。

其实在上面规约中提到了哈希表，这也正是hashCode方法运用的场景之一，也是我们为什么要重写的核心。

hashCode应用场景

如果了解HashMap的数据结构，就会知道它用到“键对象”的哈希码，当我们调用put方法或者get方法对Map容器进行操作时，都是根据键对象的哈希码来计算存储位置的。如果我们对哈希码的获取没有相关保证，就可能会得不到预期的结果。

而对象的哈希码的获取正是通过hashCode方法获取的。如果自定义的类中没有实现该方法，则会采用Object中的hashCode()方法。

在Object中该方法是一个本地方法，会返回一个int类型的哈希值。可以通过将对象的内部地址转换为整数来实现的，但是Java中没有强制要求通过该方式实现。

具体实现网络上有不同的说法，有说通过内置地址转换得来，也有说“OpenJDK8默认hashCode的计算方法是通过和当前线程有关的一个随机数+三个确定值，运用Marsaglia's xorshift scheme随机数算法得到的一个随机数”获得。

无论默认实现是怎样的，大多数情况下都无法满足equals方法相同，同时hashCode结果也相同的条件。比如下面的示例重写与否差距很大。

public void test1() {
    String s = "ok";
    StringBuilder sb = new StringBuilder(s);
    System.out.println(s.hashCode() + "  " + sb.hashCode());


    String t = new String("ok");
    StringBuilder tb = new StringBuilder(s);
    System.out.println(t.hashCode() + "  " + tb.hashCode());
}

上面这段代码打印的结果为：

3548  1833638914
3548  1620303253

String实现了hashCode方法，而StringBuilder并没有实现，这就导致即使值是一样的，hashCode也不同。

上个示例中问题还不太明显，下面我们以HashMap为例，看看如果没有实现hashCode方法会导致什么严重的后果。

@Test
public void test2() {
    String hello = "hello";


    Map<String, String> map1 = new HashMap<>();
    String s1 = new String("key");
    String s2 = new String("key");
    map1.put(s1, hello);
    System.out.println("s1.equals(s2):" + s1.equals(s2));
    System.out.println("map1.get(s1):" + map1.get(s1));
    System.out.println("map1.get(s2):" + map1.get(s2));




    Map<Key, String> map2 = new HashMap<>();
    Key k1 = new Key("A");
    Key k2 = new Key("A");
    map2.put(k1, hello);
    System.out.println("k1.equals(k2):" + s1.equals(s2));
    System.out.println("map2.get(k1):" + map2.get(k1));
    System.out.println("map2.get(k2):" + map2.get(k2));
}


class Key {


    private String k;


    public Key(String key) {
        this.k = key;
    }


    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Key) {
            Key key = (Key) obj;
            return k.equals(key.k);
        }
        return false;
    }
}

实例中定义了内部类Key，其中实现了equals方法，但未实现hashCode方法。存放于Map中的value值都是字符串“hello”。

代码分两段，第一段演示当Map的key通过实现了hashCode的String时是什么效果；第二段演示了当Map的key通过未实现hashCode方法的Key对象时是什么效果。

执行上述代码，打印结果如下：

s1.equals(s2):true
map1.get(s1):hello
map1.get(s2):hello
k1.equals(k2):true
map2.get(k1):hello
map2.get(k2):null

分析结果可以看出，对于String作为key的 s1 和 s2 来说，通过equals比较相等是自然的，获得的值也是相同的。但 k1 和 k2 通过equals比较是相等，但为什么在Map中获得的结果却不一样？本质上就是因为没有重写hashCode方法导致Map在存储和获取过程中调用hashCode方法获得的值不一致。

此时在Key类中添加hashCode方法：

@Override
public int hashCode(){
    return k.hashCode();
}

再次执行，便可正常获得对应的值。

s1.equals(s2):true
map1.get(s1):hello
map1.get(s2):hello
k1.equals(k2):true
map2.get(k1):hello
map2.get(k2):hello

通过上面的典型实例演示了不重写hashCode方法的潜在后果。简单看一下HashMap中的put方法。

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}


static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}


final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
               boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    // 通过哈希值来查找底层数组位于该位置的元素p，如果p不为null，则使用新的键值对来覆盖旧的键值对
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    else {
        Node<K,V> e; K k;
        // (二者哈希值相等)且(二者地址值相等或调用equals认定相等)。
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            e = p;
        else if (p instanceof TreeNode)
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
        else {
            for (int binCount = 0; ; ++binCount) {
                if ((e = p.next) == null) {
                    p.next = newNode(hash, key, value, null);
                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                        treeifyBin(tab, hash);
                    break;
                }
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    break;
                p = e;
            }
        }
        // 如果底层数组中存在传入的Key，那么使用新传入的覆盖掉查到的
        if (e != null) { // existing mapping for key
            V oldValue = e.value;
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict);
    return null;
}

在上述方法中，put方法在拿到key的第一步就对key对象调用了hashCode方法。暂且不看后面的代码，如果没有重写hashCode方法，就无法确保key的hash值一致，后续操作就是两个key的操作了。

重写hashCode方法

了解了重写hashCode方法的重要性，也了解了对应的规约，那么下面我们就聊聊如何优雅的重写hashCode方法。

首先，如果使用IDEA的话，那么直接使用快捷键即可。

生成的效果如下：

@Override
public boolean equals(Object o) {
    if (this == o) {
        return true;
    }
    if (o == null || getClass() != o.getClass()) {
        return false;
    }
    Key key = (Key) o;
    return Objects.equals(k, key.k);
}


@Override
public int hashCode() {
    return Objects.hash(k);
}

根据需要可对生成的方法内部实现进行修改。在上面的实例中用到了java.util.Objects类，它的hash方法的优点是如果参数为null，就只返回 0 ，否则返回对象参数调用的hashCode的结果。Objects.hash方法源码如下：

public static int hash(Object... values) {
    return Arrays.hashCode(values);
}

其中Arrays.hashCode方法源码如下：

public static int hashCode(Object a[]) {
    if (a == null)
        return 0;


    int result = 1;


    for (Object element : a)
        result = 31 * result + (element == null ? 0 : element.hashCode());


    return result;
}

当然此处只有一个参数，也可以直接使用Objects类hashCode方法：

public static int hashCode(Object o) {
    return o != null ? o.hashCode() : 0;
}

如果是多个属性都参与hash值的情况建议可使用第一个方法。只不过需要注意，在类结构（成员变量）变动时，同步增减方法里面的参数值。

小结

当我们准备面试时，一直在背诵“实现equals方法的同时也要实现hashCode方法”，牢记这些结论并没有错。但我们也不能因为匆忙准备面试题，而忘记了这些面试题之所以频繁出现的原因是什么。当深入探索之后，会发现在那些枯燥的结论背后还有这么多不容忽视的知识点，还有这么多有意思的设计与陷阱。

文章来源：www.toutiao.com/a6865829963505861132/

以上就是W3Cschool编程狮关于Java面试题：重写了equals，还要重写hashCode？的相关介绍了，希望对大家有所帮助。

本文转载自公众号：小姐姐味道

redis 功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。

Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。

使用规范

冷热数据区分

虽然 redis支持持久化，但将所有数据存储在 redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 redis 中。低频数据可存储在 Mysql、 ElasticSearch中。

业务数据分离

不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。

消息大小限制

由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。

连接数限制

连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的 Redis 客户端连接池配置。

缓存 Key 设置失效时间

作为缓存使用的 Key，必须要设置失效时间。失效时间并不是越长越好，请根据业务性质进行设置。注意，失效时间的单位有的是秒，有的是毫秒，这个很多同学不注意容易搞错。

缓存不能有中间态

缓存应该仅作缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。第一，缓存的高可用会影响业务；第二，产生深耦合会发生无法预料的效果；第三，会对维护行产生肤效果。

扩展方式首选客户端 hash

小应用就算了

如单 redis 集群并不能为你的数据服务，不要着急扩大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在状态同步和持久化方面的性能越差。 优先使用客户端 hash 进行集群拆分。如：根据用户 id 分 10 个集群，用户尾号为 0 的落在第一个集群。

操作限制

严禁使用 Keys

Keys 命令效率极低，属于 O(N)操作，会阻塞其他正常命令，在 cluster 上，会是灾难性的操作。严禁使用，DBA 应该 rename 此命令，从根源禁用。

严禁使用 Flush

flush 命令会清空所有数据，属于高危操作。严禁使用，DBA 应该 rename 此命令，从根源禁用，仅 DBA 可操作。

严禁作为消息队列使用

如没有非常特殊的需求，严禁将 Redis 当作消息队列使用。Redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。如需要消息队列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。

严禁不设置范围的批量操作

redis 那么快，慢查询除了网络延迟，就属于这些批量操作函数。大多数线上问题都是由于这些函数引起。

1、[zset] 严禁对 zset 的不设范围操作

ZRANGE、 ZRANGEBYSCORE等多个操作 ZSET 的函数，严禁使用 ZRANGE myzset 0 -1 等这种不设置范围的操作。请指定范围，如 ZRANGE myzset 0 100。如不确定长度，可使用 ZCARD 判断长度

2、[hash] 严禁对大数据量 Key 使用 HGETALL

HGETALL会取出相关 HASH 的所有数据，如果数据条数过大，同样会引起阻塞，请确保业务可控。如不确定长度，可使用 HLEN 先判断长度

3、[key] Redis Cluster 集群的 mget 操作

Redis Cluster 的 MGET 操作，会到各分片取数据聚合，相比传统的 M/S架构，性能会下降很多，请提前压测和评估

4、[其他] 严禁使用 sunion, sinter, sdiff等一些聚合操作

禁用 select 函数

select函数用来切换 database，对于使用方来说，这是很容易发生问题的地方，cluster 模式也不支持多个 database，且没有任何收益，禁用。

禁用事务

redis 本身已经很快了，如无大的必要，建议捕获异常进行回滚，不要使用事务函数，很少有人这么干。

禁用 lua 脚本扩展

lua 脚本虽然能做很多看起来很 cool 的事情，但它就像是 SQL 的存储过程，会引入性能和一些难以维护的问题，禁用。

禁止长时间 monitor

monitor函数可以快速看到当前 redis 正在执行的数据流，但是当心，高峰期长时间阻塞在 monitor 命令上，会严重影响 redis 的性能。此命令不禁止使用，但使用一定要特别特别注意。

Key 规范

Redis 的 Key 一定要规范，这样在遇到问题时，能够进行方便的定位。Redis 属于无 scheme 的 KV 数据库，所以，我们靠约定来建立其 scheme 语义。其好处：

1. 能够根据某类 key 进行数据清理
2. 能够根据某类 key 进行数据更新
3. 能够方面了解到某类 key 的归属方和应用场景
4. 为统一化、平台化做准备，减少技术变更

一般，一个 key 需要带以下维度：业务、key 用途、变量等，各个维度使用 : 进行分隔，以下是几个 key 的实例:

user:sex 用户 10002232 的性别

msg:achi 201712 的用户发言数量排行榜

End

适当的约束是架构成熟的必要条件，通过约定能达到规范是集体开发的最高境界。Redis用的多，也要用的稳，给点约束、立点规矩，生活将变的美好。通过二次封装redis客户端，直接阻断，效果更佳。

以上就是W3Cschool编程狮关于Redis规范，这可能是最中肯的了的相关介绍了，希望对大家有所帮助。

文章转载自公众号：小姐姐味道

几乎每一个分布式系统，都会给用户提供自定义路由的功能。因为，仅通过range、mod、hash等方法，很大概率已经满足不了用户的需求。下面以一个实际场景为例，说一下数据路由的思路。

文中聊的是数据路由，不是nginx之类的。

场景

某个大型toB的应用，使用 MySQL 存储，单表数据量已达数亿，在结构变更、数据查询方面，已表现出明显的瓶颈，需要进行分库分表。

实施步骤

找到切分键

第一步就是找到切分的纬度。比如业务是按照时间纬度进行查询的，那么就把创建时间作为切分键。

此业务的切分键，是商户 id （类似于你在美团开店了，美团给你分配的唯一 id ）。由于历史原因，这个 id 是用的数据库主键 id ，而且是自增的。业务具有以下特点：

1. 业务操作是由某个商户发起的，每张表都有商户 id 字段
2. 商户的数据不均衡，有的商户有几千万，有的可能只有十几条
3. 存在部分 vip 商家，其数据量非常庞大
4. 存储大量统计需求，所以无法分表，只能分库
5. 存在遍历数据的可能，比如部分定时

切分需求一阶段

分库迫在眉睫。通过分析，部分 vip 商户，数据量巨大，把它单独转移到一个数据库中也不为过。

通过维护一个映射文件，来控制 vip 商户到数据存储流向。这时候，就需要自定义路由。

伪代码如下：

function viptable(id){
    10 => "mysql-002"
    101 => "mysql-003"
}
function router4vip(id){
    aimDb = viptable(id)
    if(aimDb) return aimDb


    return "mysql-001"
}

商户为 10，数据将落向mysql-002；商户为 101，将落向mysql-003；数据默认使用mysql-001存储。

另外，由于 id 是自动生成的自增字段，与路由存在一个先有鸡还是先有蛋的问题，所以将 id 字段修改为人工设值，延伸出另外一个配号系统，在此不多提。

切分需求二阶段

解决了 vip 商户的问题，接下来就需要解决mysql-001的问题。随着业务的发展，落在默认库上的数据越来越多，很快又遇到了瓶颈。

想到的方法是，对其一分为二。mysql-001的数据打散到两个库中。这个打散的规则，我们直接采用mod。

为什么不是一拆为三呢？主要是基于以下考虑，假设拆分后的 db 为：

mysql-001-1
mysql-001-2

这种情况下mysql-001就变成了逻辑集群。当mysql-001-1和mysql-001-2也达到了瓶颈，那我们就可以对其继续进行拆分，依然是一拆为二，这时候，mod 4就可以了，不会涉及复杂的数据迁移。

拆分后的db为：

mysql-001-1-1
mysql-001-1-2
mysql-001-2-1
mysql-001-2-2

到现在为止，我们采用了 vip 分库，mod 4分库，伪代码如下：

...


function routertable(pivot){
    0 => "mysql-001-1-1"
    1 => "mysql-001-1-2"
    2 => "mysql-001-2-1"
    3 => "mysql-001-2-2"
}


function router4mod(id){
    aimDb = router4vip(id)
    if(aimDb) return aimDb


    pivot = mod4(id)
    return routertable(pivot)
}

到现在，我们已经分了六个库了。通过裂变的模式，有着较好的扩展性。

这样就可以高枕无忧了么？

切分需求三阶段

可惜的是，我们每次扩容，都是指数级别的。下一次，就是 mod 8 ；而下下次，就是mod 16 。每次扩容，都会动一半的数据，wtf。

最后，决定在商户 id 的范围上做文章。

首先，做一个定长的商户 id ，比现有系统中的任何一个都长，主要考虑新的规则不会影响旧的路由规则。

然后，首先根据商户 id 的范围划分第一层虚拟集群，然后再根据 mod 划分第二层虚拟集群。我们的路由，现在是双层路由。

比如，我们把商户号定9位(java中int是10位)，并做如下路由表：

100 000000 - 100 100000=> 虚拟集群1
100 100000 - 100 200000=> 虚拟集群2
...

前三位，用来分第一层虚拟集群，支持899个；后6位，代表范围，最大10万。每个范围下面，都会有自己的路由规则，有的可能 mod 2，有的可能 mod 3 ，有的可能再次 range 。

好，我们加入新的集群：

mysql-range0-0 代表号段在范围1中的偶数id
mysql-range0-1

伪代码如下：

...
function router4range(id){
    if(id < 100000000){
        return router4mod(id)
    }else if
    (id in [100000000-100100000]){
        return 
            "mysql-range0-"+mod2(id)
    }
}

到此为止，我们一共有8个库，其中两个是给 vip 用的，四个是遗留的路由算法，还有两个是给新的分库规则使用。

通过三次改进，我们的路由满足：

一、 当我们发现，当商户 id 增长到100 056400，就达到瓶颈了，那么就可以新增一个新的范围，只需要改动一下路由表逻辑就ok了

二、 当某个范围内某个商户成长为 vip ，那我们就可以单独将其提取出来，增加新的 vip 库

三、 某个范围内数据热点严重，那么就可以 mod 4 进行扩容，并不影响范围外的数据

四、 商户 id 同时也有时间纬度的概念，可以针对某些旧商户进行归档清理

切分需求四阶段

系统想要预留另外一部分号段，用来提供一些测试账号，供客户试用。经历过前三轮的改造，我们可以很容易的对其进行规划。

End

为什么觉得redis-cluster的slot设计是个鸡肋呢，因为它把路由规则给定死了，要我去设计我肯定要放在驱动层。

某些架构师潇洒的来，潇洒的走，留下了不可磨灭的痕迹。为了兼容这些遗留系统的路由代码，分支会更加复杂，每一个公司都有一堆故事，无非是骂娘和被骂。稳定性重如山，路由代码可能是最重要的没技术含量的if else。一动，都得死。

就问你怕不怕？

以上就是W3Cschool编程狮关于现实中的路由规则，可能比你想象中复杂的多的相关介绍了，希望对大家有所帮助。

助你入门 git 的简明指南，木有高深内容 ;)

• 来源：http://rogerdudler.github.io/git-guide/index.zh.html
• 作者：罗杰·杜德勒
• 感谢：@tfnico, @fhd和 Namics
• 如有纰漏，请在 github 提报问题

安装

下载 git OSX 版

下载 git Windows 版

下载 git Linux 版

创建新仓库

创建新文件夹，打开，然后执行

git init

以创建新的 git 仓库。

检出仓库

执行如下命令以创建一个本地仓库的克隆版本：

git clone /path/to/repository

如果是远端服务器上的仓库，你的命令会是这个样子：

git clone username@host:/path/to/repository

工作流

你的本地仓库由 git 维护的三棵“树”组成。第一个是你的 工作目录，它持有实际文件；第二个是 暂存区（Index），它像个缓存区域，临时保存你的改动；最后是 HEAD，它指向你最后一次提交的结果。

添加和提交

你可以提出更改（把它们添加到暂存区），使用如下命令：

git add <filename>
git add *

这是 git 基本工作流程的第一步；使用如下命令以实际提交改动：

git commit -m "代码提交信息"

现在，你的改动已经提交到了 HEAD，但是还没到你的远端仓库。

推送改动

你的改动现在已经在本地仓库的 HEAD 中了。执行如下命令以将这些改动提交到远端仓库：

git push origin master

可以把 master 换成你想要推送的任何分支。

如果你还没有克隆现有仓库，并欲将你的仓库连接到某个远程服务器，你可以使用如下命令添加：

git remote add origin <server>

如此你就能够将你的改动推送到所添加的服务器上去了。

分支

分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”分支。在其他分支上进行开发，完成后再将它们合并到主分支上。

创建一个叫做“feature_x”的分支，并切换过去：

git checkout -b feature_x

切换回主分支：

git checkout master

再把新建的分支删掉：

git branch -d feature_x

除非你将分支推送到远端仓库，不然该分支就是 不为他人所见的：

git push origin <branch>

更新与合并

要更新你的本地仓库至最新改动，执行：

git pull

以在你的工作目录中 获取（fetch） 并 合并（merge） 远端的改动。 要合并其他分支到你的当前分支（例如 master），执行：

git merge <branch>

在这两种情况下，git 都会尝试去自动合并改动。遗憾的是，这可能并非每次都成功，并可能出现冲突（conflicts）。 这时候就需要你修改这些文件来手动合并这些冲突（conflicts）。改完之后，你需要执行如下命令以将它们标记为合并成功：

git add <filename>

在合并改动之前，你可以使用如下命令预览差异：

git diff <source_branch> <target_branch>

标签

为软件发布创建标签是推荐的。这个概念早已存在，在 SVN 中也有。你可以执行如下命令创建一个叫做 1.0.0 的标签：

git tag 1.0.0 1b2e1d63ff

1b2e1d63ff 是你想要标记的提交 ID 的前 10 位字符。可以使用下列命令获取提交 ID：

git log

你也可以使用少一点的提交 ID 前几位，只要它的指向具有唯一性。

log

如果你想了解本地仓库的历史记录，最简单的命令就是使用:

git log

你可以添加一些参数来修改他的输出，从而得到自己想要的结果。 只看某一个人的提交记录:

git log --author=bob

一个压缩后的每一条提交记录只占一行的输出:

git log --pretty=oneline

或者你想通过 ASCII 艺术的树形结构来展示所有的分支, 每个分支都标示了他的名字和标签:

git log --graph --oneline --decorate --all

看看哪些文件改变了:

git log --name-status

这些只是你可以使用的参数中很小的一部分。更多的信息，参考：

git log --help

替换本地改动

假如你操作失误（当然，这最好永远不要发生），你可以使用如下命令替换掉本地改动：

git checkout -- <filename>

此命令会使用 HEAD 中的最新内容替换掉你的工作目录中的文件。已添加到暂存区的改动以及新文件都不会受到影响。

假如你想丢弃你在本地的所有改动与提交，可以到服务器上获取最新的版本历史，并将你本地主分支指向它：

git fetch origin
git reset --hard origin/master

实用小贴士

内建的图形化 git：

gitk

彩色的 git 输出：

git config color.ui true

显示历史记录时，每个提交的信息只显示一行：

git config format.pretty oneline

交互式添加文件到暂存区：

git add -i

链接与资源

图形化客户端

• GitX (L) (OSX, 开源软件)
• Tower (OSX)
• Source Tree (OSX, 免费)
• GitHub for Mac (OSX, 免费)
• GitBox (OSX, App Store)

指南和手册

• Git 社区参考书
• 专业 Git
• 像 git 那样思考
• GitHub 帮助
• 图解 Git

文章转载自公众号：小姐姐味道

这年头，你看到的东西未必就是你认为的东西。一个 mysql 协议的后面，可能是tidb；一个 linux 机器后面，可能是一个精简的 docker ；你觉得xjjdog是个女的，但可能ta自己也不太清楚；而当你大呼 php 万岁的时候，可能是研发人员和你开个玩笑，重写了后缀，而后端用的却是 java。

大家都知道 redis 速度快，但它的容量和内存容量有关，很容易达到瓶颈。有些互联网公司，直接使用 redis 作为后端数据库（在下佩服）。当业务量暴增，就面临一个 redis 容量和价格的权衡问题。改业务代码是来不及了，只好用一些持久化存储 ，来模拟 redis 的一些数据结构。

redis 支持近十种数据类型，最常用的有5种。string、hash、zset、set、list等。本文将针对几种常见的数据结构，探讨一下常用操作的模拟实现。

其实，我们所需要开发的，就是一个redis代理proxy。redis的客户端，连接上我们的代理之后，会进行协议解析。解析出来的命令，将会被模拟，然后根据配置的路由，定位到相应的mysql中。

也就是你所使用的redis，其实使用mysql来存储数据的。没有rdb，也没有aof。

Redis是文本协议

redis是文本协议，协议名称叫做RESP。RESP 是 Redis 序列化协议的简写。它是一种直观的文本协议，优势在于实现异常简单，解析性能极好。

如图，Redis 协议将传输的结构数据，可以总结为 5 种最小单元类型。每个单元结束时，统一加上回车换行符号 \r\n 。

下面是几个规则：

单行字符串 以 + 开头；
多行字符串 以 $ 开头，后跟字符串长度；
整数值 以 : 开头，后跟整数的字符串形式；
错误消息 以 - 符号开头；
数组 以 * 号开头，后跟数组的长度；

比如，下面这个就是数组[9,9,6]的报文。

*3\r\n:9\r\n:9\r\n:6\r\n

所以这个协议的解析和拼装，是非常简单的。拿netty来说，就有codec-redis 模块供我们使用。

实现：数据结构设计

在数据表的设计上，我们发现，kv和hash在效率上没有什么差别，因为它能够直接根据key定位到。

反倒是zset，由于有排序的功能，造成了很多操作的执行效率都不尽人意。

另外，由于我们不同的数据结构，是使用不同的表进行存储的。所以删除操作，要在每张表上都执行一遍。

kv设计

kv，即string，是redis里最基本的数据类型。一个key对应一个value，string类型的值最大能存储512MB。

设计专用的数据库表rstore_kv，其中，rkey是主键。

rkey        varchar
val     varchar
lastTime    bigint

set操作

insert into rstore_kv("rkey","val","lastTime") values($1,$2,$3)
on duplicate key update set "val"=$2,"lastTime"=$3

get操作

select val from rstore_kv where "rkey" = $1

del操作

delete from rstore_kv where "rkey" = $1

exists操作

select count(*) as n from rstore_kv where  "rkey" = $1

ttl操作

select lastTIme from rstore_kv  where  "rkey" = $1

hash设计

hash 是一个键值(key=>value)对集合。hash 特别适合用于存储对象。

设计专用的数据库表rstore_hash，其中，rkey和hkey是联合主键。

rkey        varchar
hkey        varchar
val     varchar
lastTime    bigint

hset操作

insert into rstore_hash("rkey","hkey","val","lastTime") values($1,$2,$3,$4)
on duplicate key update set "val"=$3,"lastTime"=$4

hget操作

select val from rstore_hash where "rkey" = $1 and "hkey" = $2

hgetall操作

select hkey,val from rstore_hash where "rkey" = $1

hdel操作

delete from rstore_hash where "rkey" = $1 and "hkey" = $2

del操作

delete from rstore_hash where "rkey" = $1

hlen,hexists操作

select count(*) as num from rstore_hash where "rkey" = $1

ttl操作

select max(lastTIme) from rstore_hash  where  "rkey" = $1

zset设计

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。它的底层结构是跳跃表，效率特别高，但是会占用大量内存。

设计专用的数据库表rstore_zset，其中，rkey和member是联合主键。

rkey        varchar
member        varchar
score     double
lastTime    bigint

zadd操作

insert into rstore_zset("rkey","member","score","lastTime") values($1,$2,$3,$4) on duplicate key update update set "score"=$3,"lastTime"=$4

zscore操作

select score from rstore_zset where "rkey" = $1 and "member" = $2

zrem操作

delete from rstore_zset where "rkey" = $1 and "member" = $2"

zcard,exists操作

select count(*) as num from rstore_zset where "rkey" = $1

zcount操作

select count(*) as num from rstore_zset where "rkey" = $1 and score>=$2 and score<=$3

zremrangebyscore操作

delete from rstore_zset where "rkey" = $1 and score>=$2 and score<=$3

zrangebyscore操作

select member,score from rstore_zset
where "rkey" = $1 and score>=$2 and score<=$3 order by score asc,member asc

zrange操作

select member,score from rstore_zset
where "rkey" = $1 order by score asc offset $2 limit $3

zrank操作

select rank from (select member,rank() over (order by "score" asc, "lastTime" asc) as rank from rstore_zset where "rkey" = $1 ) m where m."member"= $2;

ttl操作

select max(lastTIme) from rstore_zset  where  "rkey" = $1

del操作

delete from rstore_zset where "rkey" = $1

set设计

Redis的Set是string类型的无序集合。

设计专用的数据库表rstore_set，其中，rkey和member是联合主键。

rkey        varchar
member        varchar
lastTime    bigint

sadd操作

insert into rstore_set("rkey","member","lastTime") values($1,$2,$3)
on duplicate key update update set "lastTime"=$3

scard操作

select count(*) as num from rstore_set where "rkey" = $1

sismember操作

select member from rstore_set where "rkey" = $1 and "member" = $2

smembers操作

select member from rstore_set where "rkey" = $1

srem操作

delete from rstore_set where "rkey" = $1 and "member" = $2

del操作

delete from rstore_set where "rkey" = $1

ttl操作

select max(lastTIme) from rstore_set  where  "rkey" = $1

End

本篇文章仅仅模拟了最常用数据结构的最常用功能，有很多很多功能是不支持的，比较明显的就是分布式锁setnx等。所以这个proxy层的开发，要想做到ok，并不是那么简单。

同时，我们以一种模拟的视角，来看一下redis的数据结构，在关系型数据库中的表现形式。这样，更能够加深我们对redis的认识，明白它存在的价值。

以上就是W3Cschool编程狮关于架构秘笈：移花接木。使用mysql模拟redis的相关介绍了，希望对大家有所帮助。

文章转载自公众号：小姐姐的味道

笔者曾经维护过千个 redis 实例，这些实例采用的简单主从结构，集群方案主要是客户端jar包。刚开始，个人并不是太喜欢redis cluster，因为它的路由实在是太死板，运维复杂。

但官方在推这个东西，注定了它的应用越来越广泛，这在平常的交流中就能够发现。虽然有这样那样的缺点，但总抵挡不了权威推动的浪潮。随着redis cluster越来越稳定，是时候和redis cluster来一次灵魂交流了。

简介

redis cluster是亲生的集群方案，目前，在高可用和稳定性方面，都有了很大的进步。据统计和观察，采用redis cluster架构的公司和社区越来越多，已经成为事实的标准。它的主要特点就是去中心化，无需proxy代理。其中一个主要设计目标就是达到线性可扩展性（linear scalability）。

仅仅靠redis cluster服务器本身，并不能完成官方承诺的功能。广义上的redis cluster应该既包含redis服务器，又包含客户端实现比如jedis等。它们是一个整体。

分布式存储无非就是处理分片和副本。 对redis cluster来说，核心概念就是槽（slot），了解了它，基本就了解了集群的管理方式。

优缺点

当了解这些特性以后，运维上其实是更简单了。我们先看下比较明显的优缺点。

优点

1、不再需要额外的Sentinel集群，为使用者提供了一致的方案，减少了学习成本。 2、去中心架构，节点对等，集群可支持上千个节点。 3、抽象出了slot概念，针对slot进行运维操作。 4、副本功能能够实现自动故障转移，大部分情况下无需人工介入。

缺点

1、客户端要缓存部分数据，实现Cluster协议，相对复杂。 2、数据是通过异步复制的，不能保证数据的强一致性。 3、资源隔离困难，经常流量不均衡，尤其是多个业务共用集群的时候。数据不知道在哪里，针对热点数据，也无法通过专项优化完成。 4、从库是完全的冷备，无法分担读操作，真是太太浪费了。需要做额外工作。 5、MultiOp和Pipeline支持有限，老代码要是进行架构升级，要小心了。 6、数据迁移是基于key而不是基于slot的，过程较慢。

基本原理

从槽到key，定位过程明显就是一个双层的路由。

key的路由

redis cluster和常用的一致性hash没什么关系，它主要采用了哈希槽的概念。当需要在其中存取一个key时，redis客户端会首先对这个key采用crc16算法算出一个值，然后对这个值进行mod操作。

crc16(key)mod 16384

所以，每个key都会落在其中的一个hash槽上。16384 等同于 2^14（16k），redis节点发送心跳包时，需要把所有的槽信息放在这个心跳包里，所以要竭尽全力的优化，感兴趣的可以看下为什么默认的槽数量是 16384 。

服务端简单原理

上面谈到，redis cluster共定义了 16384 个槽，所有的集群操作都是围绕着这个槽数据进行编码。服务端使用一个简单的数组存储这些信息。

对于判断有无的操作，使用bitmap来存储是最节省空间的。redis cluster就是使用一个叫做slot的数组来保存当前节点是否持有了这个槽。

如图，这个数组的长度为 16384/8=2048 Byte，那么就可以使用 0 或者 1 来标识本节点对某个槽是否拥有。

其实，只需要第一份数据ClusterState也能完成操作，保存另外一个维度的Slot数组，能够方便编码和存储。一个节点除了会将自己负责处理的槽记录在两个地方（clusterNode结构的slots和numslots），它还会将自己的slots数组通过消息发送给集群中的其他节点，以此来告诉其他节点自己目前拥有的槽。

当数据库中的 16384 个槽都有节点在处理时，集群处于上线状态（ok）；相反地，如果数据库中有任何一个槽没有得到处理，那么集群处于下线状态（fail）。

当客户端向节点发送相关命令时，接收命令的节点会计算出命令要处理的key属于哪个槽，并检查这个槽是否指派给了自己。如果不是自己的，会指引客户端到正确的节点。

所以，客户端连接集群中的任意一台机器，都能够完成操作。

安装一个6节点集群

准备工作

假如我们要组装一个3分片的集群，每个分片有一个副本。那么总共需要的node实例就有 3*2=6 个。redis可以通过指定配置文件的方式启动，我们所做的工作就是修改配置文件。

复制6份默认的配置文件。

for i in {0..5}
do
cp redis.conf  redis-700$i.conf
done

修改其中的配置文件内容，拿redis-7000.conf来说，我们要启用它的cluster模式。

cluster-enabled yes
port 7000
cluster-config-file nodes-7000.conf

nodes-7000.conf会保存一些集群信息到当前节点，所以需要独立。

启动&关闭

同样的，我们使用脚本来启动它。

for i in {0..5}
do
nohup ./redis-server redis-700$i.conf &
done

为了演示，我们暴力把它关闭。

ps -ef| grep redis | awk '{print $2}' | xargs kill -9

组合集群

我们使用redis-cli进行集群的组合。redis将自动完成这个过程。这一系列的过程，是通过发送指令给每个节点进行组合的。

./redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

几个高级原理

节点故障

集群中的每个节点都会定期地向集群中的其他节点发送ping消息，以此来检测对方是否在线，如果接收ping消息的节点没有在规定的时间内返回pong消息，那么发送ping消息的节点就会将接收ping消息的节点标记为疑似下线（PFAIL）。

如果在一个集群里面，半数以上节点都将某个主节点 x 报告为疑似下线，那么这个主节点x将被标记为已下线（FAIL），将x标记为FAIL的节点会向集群广播一条关于 x 的FAIL消息，所有收到这条FAIL消息的节点都会立即将 x 标记为FAIL。

大家可以注意到这个过程，与 es 和 zk 的节点判断类似，都是半数以上才进行判断，所以主节点的数量一般都是奇数。由于没有最小组群配置，理论上会有脑裂（暂时并未遇到过）。

主从切换

当一个节点发现自己的主节点进入fail状态，将会从这个节点的从节点当中，选出一台，执行slaveof no one命令，变身为主节点。

新的节点完成自己的槽指派以后，会向集群广播一条pong消息，以便让其他节点立即知道自己的这些变化。它告诉别人：我已经是主节点了，我已经接管了有问题的节点，成为了它的替身。

redis内部对集群的这些管理，大量使用了已经定义好的这些指令。所以这些指令不仅仅供我们从命令行使用，redis自己内部也用。

数据同步

当一台从机连接到master之后，会发送一个sync指令。master在收到这个指令后，会在后台启动存盘进程。执行完毕后，master将整个数据库文件传输到slave，这样就完成了第一次全量同步。

接下来，master会把自己收到的变更指令，依次传送给slave，从而达到数据的最终同步。从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

数据丢失

redis cluster中节点之间使用异步复制，并没有类似kafka这种ack的概念。节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升，完成这个过程注定了需要时间。在发生故障的过程中就容易存在窗口，导致丢失写入的数据。比如以下两种情况。

一、命令已经到到master，此时数据并没有同步到slave，master会对客户端回复ok。如果这个时候主节点宕机，那么这条数据将会丢失。redis这样做会避免很多问题，但对一个对数据可靠性要求较高的系统，是不可忍受的。

二、由于路由表是在客户端存放的，存在一个时效问题。如果分区导致一个节点不可达，提升了某个从节点，但原来的主节点在这个时候又可以用了（并未完成failover）。这个时候一旦客户端的路由表并没有更新，那么它将会把数据写到错误的节点，造成数据丢失。

所以redis cluster在通常情况下运行的很好，在极端情况下某些值丢失问题，目前无解。

复杂的运维

redis cluster的运维非常的繁杂，虽然已经进行了抽象，但这个过程依然不简单。有些指令，必须在详细了解它的实现原理之后，才能真正放心的去用。

上图就是扩容会用到的一些命令。在实际使用的过程中，可能需要多次频繁地输入这些命令，且输入的过程中还要监视它的状态，所以基本上是不可能人工跑这些命令的。

运维的入口有两个。一个是使用redis-cli连接任意一台，然后发送cluster打头的命令，这部分命令大多数是对槽进行操作。 在开始组合集群时，就是反复调用这些命令进行的具体逻辑执行。

另外一个入口是使用redis-cli命令，加上--cluster参数和指令。这种形式主要是用来管控集群节点信息 ，比如增删节点等。所以推荐使用这种方式。

redis cluster提供了非常复杂的命令，难于操作和记忆。推荐使用类似CacheCloud的工具进行管理。

下面是几个例子。

通过向节点 A 发送 CLUSTER MEET 命令，客户端可以让接收命令的节点 A 将另一个节点 B 添加到节点 A 当前所在的集群里面：

CLUSTER MEET  127.0.0.1 7006

通过cluster addslots命令，可以将一个或者多个槽指派给某个节点负责。

127.0.0.1:7000> CLUSTER ADDSLOTS 0 1 2 3 4 . . . 5000

设置从节点。

CLUSTER REPLICATE <node_id>

redis-cli —cluster

redis-trib.rb是官方提供的Redis Cluster的管理工具，但最新版本已经推荐使用redis-cli进行操作。

向集群中添加新节点

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7007 --cluster-replicas 1

从集群中删除节点

redis-cli --cluster del-node 127.0.0.1:7006 54abb85ea9874af495057b6f95e0af5776b35a52

迁移槽到新的节点

redis-cli --cluster reshard 127.0.0.1:7006 --cluster-from 54abb85ea9874af495057b6f95e0af5776b35a52 --cluster-to 895e1d1f589dfdac34f8bdf149360fe9ca8a24eb  --cluster-slots 108

类似的命令还有很多。

create：创建集群 check：检查集群 info：查看集群信息 fix：修复集群 reshard：在线迁移slot rebalance：平衡集群节点slot数量 add-node：添加新节点 del-node：删除节点 set-timeout：设置节点的超时时间 call：在集群所有节点上执行命令 import：将外部redis数据导入集群

其他方案概览

主从模式

redis最早支持的，就是M-S模式，也就是一主多从。redis单机qps可达到 10w+，但是在某些高访问量场景下，依然不太够用。一般通过读写分离来增加slave，减少主机的压力。

既然是主从架构，就面临着同步问题，redis主从模式的同步分为全同步和部分同步。当刚创建一个从机的时候，不可避免的要进行一次全量同步。等全量同步结束之后，进入增量同步阶段。这个和redis cluster是没什么区别的。

这种模式还是比较稳定的，但要额外做一些工作。用户需要自行开发主从切换的功能，也就是使用哨兵去探测每个实例的健康状况，然后通过指令进行集群状态的改变。

当集群规模增大，主从模式会很快遇到瓶颈。所以一般会采用客户端hash的方法进行扩展，包括类似于memcached的一致性哈希。

客户端hash的路由可能会很复杂，通常会通过发布jar包或者配置的方式维护这些meta信息，这也给线上环境增加了很多不确定性。

不过，通过加入类似ZK主动通知的功能，将配置维护在云端，可以显著降低风险。笔者曾经维护过的几千个redis节点，就是用这种方式进行管理的。

代理模式

代码模式在redis cluster出现之前，非常流行，比如codis。代理层通过把自己模拟成一个redis，接收来自客户端的请求，然后按照自定义的路由逻辑进行数据分片以及迁移，而业务方不需要改动任何代码。除了能够平滑的进行扩容，一些主从切换、FailOver的功能也在代理层完成，客户端甚至可以没有任何感知。这类程序又称为分布式中间件。

一个典型的实现如下图，背后的redis集群甚至可以是混合的。

但这种方式的缺点也是显而易见的。首先，它引入了一个新的代理层，在结构上、运维上都显复杂。需要进行大量的编码，比如failover、读写分离、数据迁移等。另外，proxy层的加入，对性能也有相应的损耗。

多个proxy一般使用lvs等前置进行负载均衡的设计，如果proxy层的机器很少而后端redis的流量很高，那么网卡会成为主要的瓶颈。

Nginx也可以作为redis的代理层，比较专业的说法叫做Smart Proxy。这种方式较为偏门，如果你对nginx比较熟悉，不失为一种优雅的做法。

使用限制和坑

redis的速度特别的快。一般越快的东西，出问题的时候造成的后果越大。

不久之前，写过一篇针对于redis的规范：《Redis规范，这可能是最中肯的了》。规范和架构一样，适合自己公司环境的，才是最好的，但会提供一些起码的思路。

严格禁止的东西，一般都是前人踩坑的地方。除了这篇规范的内容，对于redis-cluster，补充以下几点。

1、redis cluster号称能够支持1k个节点，但你最好不要这么做。当节点数量增加到10，就能够感受到集群的一些抖动。这么大的集群证明你的业务已经很牛x了，考虑一下客户端分片吧。

2、一定要避免产生热点，如果流量全部打到了某个节点，后果一般很严重。

3、大key不要放redis，它会产生大量的慢查询，影响正常的查询。

4、如果你不是作为存储，缓存一定要设置过期时间。占着茅坑不拉屎的感觉是非常讨厌的。

5、大流量，不要开aof，开rdb即可。

6、redis cluster的操作，少用pipeline，少用multi-key，它们会产生大量不可预料的结果。

以上是一些补充，更全还是参考规范吧 《Redis规范，这可能是最中肯的了》。。。

End

redis 的代码才那么一丁点，肯定不会实现非常复杂的分布式供能。 redis 的定位就是性能、水平伸缩和可用性，对于简单的、一般流量的应用，已经足够了。生产环境无小事，对于复杂的高并发应用，注定了是一个组合的优化方案。

以上就是W3Cschool编程狮关于与亲生的Redis Cluster，来一次灵魂交流的相关介绍了，希望对大家有所帮助。

文章转载自公众号：小姐姐味道

redis速度快，可靠性高，是互联网公司的标配。它有单机、主从、哨兵、Cluster等四种部署模式。

下面，仅从部署模式上，来说明一下它们的优缺点。

单机模式

单机模式的redis非常简单，你只需要启动一个单一的节点就可以了，安装过程不超过5分钟。

通过redis-benchmark测试简单的命令，QPS可达到10w以上，不得不说非常的让人惊艳了。

单机模式的问题也非常明显。缺乏高可用的机制！

假如redis进程死了，进程就只能够穿透到底层的数据库中，对业务来说非常的危险。如果你把redis当作数据存储来用，情况会更加严重，甚至会丢失数据。

主从模式

所以最基本的redis部署，都会增加一个或者多个slave（现在叫replication）。

当主redis发生问题的时候，能够选取一个slave顶上去。

非常可惜的是，这种模式和传统的MySQL主从一样，切换起来比较蛋疼，需要借助外部的工具，比如keepalived等辅助进行切换，部署和维护难度直接飙升。

keepalived是一个基于VRRP协议来实现的高可用方案，通过 IP 漂移实现高可用。从描述上就可以看出它需要网络管理员的参与，和我们轻量级的redis背道而驰。

哨兵模式

哨兵模式就是使用额外的进程来替换keepalived的功能，对redis进程的存活性进行判断。在哨兵模式下，一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。

但哨兵模式一个最大的问题，就是哨兵的数量太多，至少需要3个节点。

对redis进行仲裁的时候，需要n/2+1个节点投票才能确认，这也是分布式系统的一般做法 (quorum)。和Zookeeper类似，哨兵节点做成奇数个，是非常合适的。

哨兵模式可以通过sentinel monitor配置同时检测多套集群，在集群数量适中的时候，还是比较好用的。

但哨兵模式有很多隐藏的坑，比如哨兵的启动，必须在master存活的情况下才能正常运行；另外，如果你的redis配置文件中使用RENAME屏蔽了一些危险命令时，哨兵也不能够启动。

客户端在连接redis的时候，就不能再直接连接redis的实例，它需要从哨兵转上一圈，以便获取一些变更信息。

集群模式

《与亲生的Redis Cluster，来一次灵魂交流》

集群模式可以说是这里面最优雅的方式了。你只需要部署多个对等的redis节点，然后使用客户端命令进行组群就可以了。

ip=192.169.0.23
./bin/redis-cli --cluster create  $ip:7001 $ip:7002 $ip:7003 $ip:7004 $ip:7005 $ip:7006 --cluster-replicas 1

它对节点的要求也是比较多的，一般是采用6个节点，三主三从。当节点超过10个，它的协调性就不那么灵活了，所以单集群的存储和性能上限也很快能到达。

集群模式的一些缺点很隐蔽。它的服务端节点倒是非常稳定了，但有些命令会严重影响性能。比如mget,pipeline等。它们需要把请求分散到多个节点执行、再聚合。节点越多，性能越低。

在下面这篇文章中，我们详细的描述了一些比较通用的redis使用规范，有些就是为了规避cluster模式引起的一些问题。

《Redis规范，这可能是最中肯的了》

其他方案

可以看到redis的这些集群模式，都不是完美的。应对小型的服务可能没有问题，如果是大型的集群和服务，这些部署方式对运维上，使用上来说，都有非常大的挑战。

使用客户端hash的方法，是大型互联网中常用的方式。参考下面的文章，现实中的路由规则，可能会相当复杂，但请求总能够精确的落在某个小的群组上面。

《现实中的路由规则，可能比你想象中复杂的多》

对于管理大型集群来说，我倒是倾向于主从模式，然后使用Java或者其他语言开发一个可以集中管控的哨兵系统，对上千个集群进行管理。

由于Redis是文本协议，协议非常简单，Netty甚至直接内置了它的解析器，所以开发这么一个哨兵系统是非常简单的。

一些中间层代理软件，也能分担一些路由工作，但由于是中间层，涉及到一层网络转发，对Redis这种以速度取胜的服务来说，就不是很实用。

变种有更多，比如下面这篇文章，使用的是Redis协议，但后端存储却是MySQL，所以你的命令会是被阉割的。

《架构秘笈：移花接木。使用mysql模拟redis》

从上面的描述中我们就可以看出，Redis 能用是一回事，用好是另一回事。

你可能花了一天时间搭建了一个单节点的 Redis ；我可能花了一周时间写了个 Java 版的哨兵，还有很多BUG。这两者在不懂技术的领导眼里，是没有区别的–它们都满足了业务的需求。但也不必过分计较，现实一般都比较残酷，计算机系统也没有想象中的那么稳定，墨菲定律总有一个时间会教会他们做人。

当然，领导每天都在教我做人。

以上就是W3Cschool编程狮关于Redis集群方案这么多，我该用哪种呢？的相关介绍了，希望对大家有所帮助。