大数据技术之_21_Redis学习_01_NoSQL 入门概述 + Redis 入门介绍、安装 + Redis 的5种数据类型
第一章 NoSQL 入门概述1.1 入门概述1.1.1 单机 MySQL 的美好年代1.1.2 Memcached(缓存) + MySQL + 垂直拆分1.1.3 MySQL 主从复制--读写分离1.1.4 分表分库 + 水平拆分 + MySQL 集群1.1.5 MySQL 的扩展性瓶颈1.1.6 今天是什么样子？1.1.7 为什么用 NoSQL？1.2 NoSQL 是什么？1.3 NoSQL 能干啥？1.4 NoSQL 有哪些？1.5 NoSQL 怎么玩？1.2 4V + 3高1.3 云计算--互联网云架构1.3.1 当前的互联网江湖1.3.2 传统行业 Java 工程师1.3.1 大型互联网架构架构1.3.2 云大具体应用1.3.3 需要掌握的技术1.3.4 软件架构设计1.4 当下的 NoSQL 经典应用1.5 在分布式数据库中 CAP 原理（CAP + BASE）第二章 Redis 入门介绍2.1 入门概述2.2 Redis 的安装2.3 Redis 启动后杂项基础知识讲解第三章 Redis 数据类型
第一章 NoSQL 入门概述
1.1 入门概述
1.1.1 单机 MySQL 的美好年代
在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。
在那个时候，更多的都是静态网页，动态交互类型的网站不多。
上述架构下，我们来看看数据存储的瓶颈是什么？
1、数据量的总大小：一个机器放不下时
2、数据的索引（B+ Tree）：一个机器的内存放不下时
3、访问量（读写混合）：一个实例不能承受
如果满足了上述 1 or 3 个，进化……
1.1.2 Memcached(缓存) + MySQL + 垂直拆分
后来，随着访问量的上升，几乎大部分使用 MySQL 架构的网站在数据库上都开始出现了性能问题，web 程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台 web 机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的 IO 压力。在这个时候，Memcached 就自然的成为一个非常时尚的技术产品。
Memcached 作为一个独立的分布式的缓存服务器，为多个 web 服务器提供了一个共享的高性能缓存服务，在 Memcached 服务器上，又发展了根据 hash 算法来进行多台 Memcached 缓存服务的扩展，然后又出现了一致性 hash 来解决增加或减少缓存服务器导致重新 hash 带来的大量缓存失效的弊端。
1.1.3 MySQL 主从复制--读写分离
由于数据库的写入压力增加，Memcached 只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用
主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql 的 master-slave 模式成为这个时候的网站标配了。
1.1.4 分表分库 + 水平拆分 + MySQL 集群
在 Memcached 的高速缓存，MySQL 的主从复制，读写分离的基础之上，这时 MySQL 主库的写压力开始出现瓶颈，而数据量的持续猛增，由于 MyISAM 使用表锁，在高并发下会出现严重的锁问题，大量的高并发 MySQL 应用开始使用 InnoDB 引擎代替 MyISAM。
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL 推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然 MySQL 推出了 MySQL Cluster 集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。
1.1.5 MySQL 的扩展性瓶颈
MySQL 数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如 1000 万 4KB 大小的文本就接近 40GB 的大小，如果能把这些数据从 MySQL 省去，MySQL 将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL 的扩展性差（需要复杂的技术来实现），大数据下 IO 压力大，表结构更改困难，正是当前使用 MySQL 的开发人员面临的问题。
1.1.6 今天是什么样子？
1.1.7 为什么用 NoSQL？
为什么使用 NoSQL ?
今天我们可以通过第三方平台（如：Google、Facebook等）可以很容易的访问和抓取数据。用户的个人信息、社交网络、地理位置、用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那 SQL 数据库已经不适合这些应用了，NoSQL 数据库的发展也却能很好的处理这些大的数据。
1.2 NoSQL 是什么？
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是 SQL”，泛指非关系型的数据库。随着互联网 web2.0 网站的兴起，传统的关系数据库在应付 web2.0 网站，特别是超大规模和高并发的 SNS 类型的 web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL 数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
例如谷歌或 Facebook 每天为他们的用户收集万亿比特的数据。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
1.3 NoSQL 能干啥？
KV -- 键值对
Cache -- 缓存
Persistence -- 持久化
1.4 NoSQL 有哪些？
Redis
Memcache
MongoDB
1.5 NoSQL 怎么玩？
Hello World
类比
递推
各大网站、博客、论坛、微信公众号
1.2 4V + 3高
4V：
海量(大量) Volume
多样 Variety
实时(高速) Velocity
低价值密度 Value
参考链接：https://www.cnblogs.com/chenmingjun/p/10335265.html#_label0_1
3高：
高并发
高可扩
高性能
1.3 云计算--互联网云架构
1.3.1 当前的互联网江湖
云计算大数据工程师 = 云大。
人算不如天算，天算就是云计算。
架构即技术，技术即人生。
云计算 和 大数据 是不分家的。就相当于语文和历史的关系。
买书容易看书难，搬家还麻烦！
天上飞的理论是相通的，落地的产品各不相同。
我们身处“争雄图霸”的 IT 乱世
滴滴 + 快的 合并
美团 + 大众点评 合并
携程 + 去哪网儿 合并
海底捞
支付宝会记录你的消费轨迹 => 蚂蚁金服 -> 花呗+借呗+芝麻信用 => 广告的分类推送 + 精确营销
百度 -- 熊厂、狼厂、蓝厂
百度的 Logo 是一个蓝色的熊爪子，百度CEO李彦宏给百度员工的一封公开信：《鼓励狼性淘汰小资》。
腾讯 -- 鹅厂
腾讯的 Logo 是一只企鹅，企鹅也是鹅。
迅雷 -- 鸟厂
360 -- 绿厂、数字公司
阿里巴巴 -- 猫厂、东厂、西厂
阿里巴巴是因为旗下天猫的 Logo。
新浪 -- 渣浪
起因是 up 主使用外链投稿曾多次被新浪审核但又无故删除，使得UP主们抓狂，从此就有了“战渣浪”的定义。
网易 -- 猪厂
网易 CEO 丁磊在之前养过一段时间的猪。
搜狐 -- 狐厂
搜狐的吉祥物是一只红色大尾巴的小狐狸。
京东 -- 狗厂
小米 -- 粮厂、杂粮、粗粮
盛大 -- 无花名
据说在盛大工作过1-2年叫盛斗士；3-5年叫必盛客;6-9年叫斗战盛佛；10年以上叫齐天大盛。
1.3.2 传统行业 Java 工程师
01 图
02 图
03 图
问题：
用户端：公司发展，用户过万，在线用户上千，应用服务器和数据库都成为瓶颈。
开发组：团队变大，所有开发人员集中针对同一个系统，冲突严重。
业务模式决定架构：
• 面向互联网海量用户提供服务
• 面向商家提供网络销售平台
• 商品种类繁多，需及时更新数据
• 全天24小时运营，快速处理客户订单
• 交易量大且不断增长，促销活动期间业务量突增
• 支持多种营销模式，逻辑复杂
• 业务模式包括自营B2C、商家B2C、广告、代发物流等
• 经营实物商品和数字商品，交付方式不同
• 支持多种安全的登录方式和支付方式
1.3.1 大型互联网架构架构
1、当当网
当当网技术架构
2、美团网
3、宜人贷
4、淘宝网
1.3.2 云大具体应用
1.3.3 需要掌握的技术
把传统的 JavaEE + 云平台整合构建？
1.3.4 软件架构设计
• 子系统的设计以及接口的定义
• 基于 Linux 下的服务器集群配置
• 负载均衡与性能提升
阿里巴巴大规模互联网实践的顶层架构图
企业级互联网架构平台的事实标准
企业信息系统演进的历程
芒果TV合作案例
1.4 当下的 NoSQL 经典应用
阿里巴巴中文站架构发展历程
阿里巴巴中文站第五代网站架构
阿里巴巴中文站第五代网站架构的使命
和我们相关的，多数据源多数据类型的存储问题
为什么要去IOE？
2008年，王坚加盟阿里巴巴成为集团首席架构师，即现在的首席技术官。这位前微软亚洲研究院常务副院长被马云定位为：将帮助阿里巴巴集团建立世界级的技术团队，并负责集团技术架构以及基础技术平台搭建。
在加入阿里后，带着技术基因和学者风范的王坚就在阿里巴巴集团提出了被称为 “去IOE”（在 IT 建设过程中，去除 IBM 小型机、Oracle 数据库及 EMC 存储设备）的想法，并开始把云计算的本质，植入阿里 IT 基因。
王坚这样概括 “去IOE” 运动和阿里云之间的关系：“去IOE” 彻底改变了阿里集团 IT 架构的基础，是阿里拥抱云计算，产出计算服务的基础。“去IOE” 的本质是分布化，让随处可以买到的 Commodity PC 架构成为可能，使云计算能够落地的首要条件。
UDSL 是什么？
1.5 在分布式数据库中 CAP 原理（CAP + BASE）
最多只能同时较好的满足两个。
CAP 理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：
• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP 的 3 进 2
CAP 理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有 NoSQL 系统能同时保证这三点。
C:强一致性 A：高可用性 P：分布式容忍性
CA -- 传统 Oracle 数据库
AP -- 大多数网站架构的选择
CP -- Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数 web 应用，其实并不需要强一致性。
因此牺牲 C 换取 P，这是目前分布式数据库产品的方向。
一致性与可用性的决择
对于 web2.0 网站来说，关系数据库的很多主要特性却往往无用武之地
数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。
数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的 web 系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是 SNS 类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL 的功能被极大的弱化了。
BASE 是什么？
BASE 就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
BASE 其实是下面三个术语的缩写：
基本可用（Basically Available）
软状态（Soft state）
最终一致（Eventually consistent）
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢？缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里 BASE 就是解决这个问题的办法。
分布式系统
分布式系统（distributed system）由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。
简单来讲：
1、分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过 RPC/RMI 之间通信和调用，对外提供服务和组内协作。
2、集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。
第二章 Redis 入门介绍
2.1 入门概述
2.2 Redis 的安装
查看端口命令复习
2.3 Redis 启动后杂项基础知识讲解
第三章 Redis 数据类型
【转载文章务必保留出处和署名，谢谢！】
