nosql

Redis 数据结构使用场景 一、redis 数据结构使用场景 原来看过 redisbook 这本书，对 redis 的基本功能都已经熟悉了，从上周开始看 redis 的源码。目前目标是吃透 redis 的数据结构。我们都知道，在 redis 中一共有5种数据结构，那每种数据结构的使用场景都是什么呢？ String——字符串 Hash——字典 List——列表 Set——集合 Sorted Set——有序集合 下面我们就来简单说明一下它们各自的使用场景： 1. String——字符串 String 数据结构是简单的 key-value 类型，value 不仅可以是 String，也可以是数字（当数字类型用 Long 可以表示的时候encoding 就是整型，其他都存储在 sdshdr 当做字符串）。使用 Strings 类型，可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受 Redis 的定时持久化（可以选择 RDB 模式或者 AOF 模式），操作日志及 Replication 等功能。除了提供与 Memcached 一样的 get、set、incr、decr 等操作外，Redis 还提供了下面一些操作： LEN niushuai ：O(1)获取字符串长度 APPEND niushuai redis ：往字符串 append 内容，而且采用智能分配内存

点击上方 "IT牧场" ，选择 "设为星标" 技术干货每日送达！ 责编：乐乐 | 链接：my.oschina.net/u/3772106/blog/1793561 00 前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 01 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。 服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： 服务器 均衡负载(如：nginx，阿里云SLB) 资源监控 分布式 数据库 主从分离，集群 DBA 表优化，索引优化，等 分布式 nosql 主从分离，集群 主从分离，集群 主从分离，集群 redis mongodb memcache cdn html css js

点击上方“朱小厮的博客”，选择“设为星标” 后台回复"书"，获取 导语：本文的缘起是回答知乎圆桌会议「分布式系统之美」的问题「如何系统性地学习分布式系统?」，后面稍微整理了一下，形成了这一篇文章（知乎 ID：kylin）。 前 言 学习一个知识之前，我觉得比较好的方式是先理解它的来龙去脉：即这个知识产生的过程，它解决了什么问题，它是怎么样解决的，还有它引入了哪些新的问题（没有银弹），这样我们才能比较好的抓到它的脉络和关键点，不会一开始就迷失在细节中。 所以，在学习分布式系统之前，我们需要解决的第一个问题是：分布式系统解决了什么问题？ 分布式系统解决了什么问题？ 第一个是单机性能瓶颈导致的成本问题，由于摩尔定律失效，廉价 PC 机性能的瓶颈无法继续突破，小型机和大型机能提高更高的单机性能，但是成本太大高，一般的公司很难承受； 第二个是用户量和数据量爆炸性的增大导致的成本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，但是单个用户或者单条数据的价值其实比软件时代（比如银行用户）的价值是只低不高，所以必须寻找更经济的方案； 第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无法容忍停止服务等故障，而要提供高可用的服务，唯一的方式就是增加冗余来完成，这样就算单机系统可以支撑的服务，因为高可用的要求，也会变成一个分布式系统。

B-树由来 定义：B-树是一类树，包括B-树、B+树、B*树等，是一棵自平衡的搜索树，它类似普通的平衡二叉树，不同的一点是B-树允许每个节点有更多的子节点。B-树是专门为外部存储器设计的，如磁盘，它对于读取和写入大块数据有良好的性能，所以一般被用在文件系统及数据库中。 先来看看为什么会出现B-树这类数据结构。 传统用来搜索的平衡二叉树有很多，如 AVL 树，红黑树等。这些树在一般情况下查询性能非常好，但当数据非常大的时候它们就无能为力了。原因当数据量非常大时，内存不够用，大部分数据只能存放在磁盘上，只有需要的数据才加载到内存中。一般而言内存访问的时间约为 50 ns，而磁盘在 10 ms 左右。速度相差了近 5 个数量级，磁盘读取时间远远超过了数据在内存中比较的时间。这说明程序大部分时间会阻塞在磁盘 IO 上。那么我们如何提高程序性能？减少磁盘 IO 次数，像 AVL 树，红黑树这类平衡二叉树从设计上无法“迎合”磁盘。 关于磁盘可参考 浅谈计算机中的存储模型（四）磁盘 上图是一颗简单的平衡二叉树，平衡二叉树是通过旋转来保持平衡的，而旋转是对整棵树的操作，若部分加载到内存中则无法完成旋转操作。其次平衡二叉树的高度相对较大为 log n（底数为2），这样逻辑上很近的节点实际可能非常远，无法很好的利用磁盘预读（局部性原理），所以这类平衡二叉树在数据库和文件系统上的选择就被 pass 了。

来源：博客园 　　 对一个大型网站系统，其架构也是重要的一个环节。 　　大型网站技术主要的挑战来自于庞大的用户、高并发以及海量的数据这三个方面。大型网站的形成就像一颗大树的成长，历尽长时间的磨练，最后枝繁叶茂，服务他人。 初始网站架构结构 起初的网站鉴于用户量、访问量较少，只需要一台服务器足以，应用程序、数据库、文件等其所有资源放在一太服务器上就已经足够满足此时的需求，这时候网站的架构就几个简单组成部分如下图 应用和数据服务分离 　　随着网站业务需求的发展，越来越多的用户进行访问，此时一台服务器渐渐不能满足需求，数据的存储空间出现屏障。于是应用程序、数据库、文件三者面临分离，各自为首分配一台服务器，这三台服务器对硬件的要求各取所需，应用服务器处理大量的业务逻辑，需求更快更大的CPU；数据库服务器对数据库的处理需要快速搜索以及缓存，需求对内存更大，对硬盘读写能力更迅速；文件服务器需求放入大量的用户资源，对硬盘空间要求更大。此时的网站的架构组成部分展示如下图 使用缓存 　　网站的架构进一步改进后可以满足了业务的发展，但是随着网站知名度提升，用户量的进一步增加，访问数据相比之前愈加频繁，数据库压力急剧上升导致网站访问出现延迟，用户的性能体验出现下滑，面临此时网站出现的性能问题，网站架构设计需要再一次的进化，鉴于网站访问也遵循二八定律，例如：新浪微博，只有经常登录的用户才会发微博，看微博

数据库是什么？ 数据库（Database System） 数据库的分类 数据库（Database System） 数据库系统（Database System），是由数据库及其管理软件组成的系统。 数据库就是存储数据的地方，传统意义上不包括文件系统 数据库是由2部分组成 db 数据库本身 – 我们看不见的 数据库管理系统 数据库的分类 现在世界上数据库分为3类 关系型数据库 RDBMS 关系数据库管理系统（Relational Database Management System：RDBMS）是指包括相互联系的逻辑组织和存取这些数据的一套程序 (数据库管理系统软件)。 主流的数据库 最出名的3大关系型数据库：MySQL Oracle MSSQL（sql server） MySQL被Oracle收购了 非关系型数据库NOSQL 不是要取代传统关系型数据库 而是补充 NOSQL的意思就是Not Only SQL 产生的原因：关系型数据库太慢了！ redis（基于内存的） mongodb（基于硬盘的） hbase（基于大数据集群的） NEWSQL 近几年才出现的 是RDBMS和NOSQL折中的数据库解决办法 来源： oschina 链接： https://my.oschina.net/u/4356138/blog/4281850

一、数据库瓶颈 不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。 1、IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。 第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。 2、CPU瓶颈 第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。 第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念： 以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。 结果： 每个库的结构都一样； 每个库的数据都不一样，没有交集； 所有库的并集是全量数据； 场景： 系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。 分析： 库多了，io和cpu的压力自然可以成倍缓解。 2、水平分表 概念： 以字段为依据，按照一定策略（hash、range等）