新商机分表方案

sell_chance表现状
当前（20190307）数据: 1.8kw
去年（201801-201901）增长数据量: 1.3kw

考虑到公司发展速度，未来的数据量肯定较去年有所上升，按一年3kw的数据量计算，3年的数据量不超过12kw。

随着数据量的不断上升，对单表操作的性能上会带来一定的影响，因此需要制定优化方案来解决此问题。

前言

提高服务的可靠性，通常采用Redis主从服务器来作读写分离。

前言

一般在项目中，最消耗性能的地方就是后端服务的数据库了。而数据库的读写频率常常都是不均匀分布的，大多情况是读多写少，并且读操作（select）还会有一些复杂的判断条件，比如 like、group、join 等等，所有会出现很多的慢查询，因此数据库很容易在读操作的环节遇到瓶颈。

前言

SUBSCRIBE、UNSUBSCRIBE和PUBLISH 三个命令实现了发布与订阅信息泛型（Publish/Subscribe messaging paradigm），在这个实现中， 发送者（发送信息的客户端）将信息发送给频道（channel）， 然后由频道将信息转发给所有对这个频道感兴趣的订阅者。

概述

分布式协调技术

　　分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成”脏数据”的后果。

　　那么怎么对这些进程进行调度呢？

　　这时候我们就需要一个协调器，来让他们有序的来访问这个资源。这个协调器就是我们经常提到的那个锁。通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。但是因为其运行所在的环境存在网络延迟等不可靠因素的，导致对数据的处理存在许多困难。目前处理分布式协调技术比较好的有Chubby(Google产品，未开源)和Zookeeper(Apache产品，开源)。

BASE

BASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。

BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

CAP

分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。

分布式锁

在单机场景下，可以使用语言的内置锁来实现进程同步。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁。

阻塞锁通常使用互斥量来实现：

概述

Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。

键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

Redis 支持很多特性，例如将内存中的数据持久化到硬盘中，使用复制来扩展读性能，使用分片来扩展写性能。

该篇直接引用MySQL