末了总结
搞定算法，口试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大口试高频知识点及解析
末了再分享一份终极手撕架构的大礼包(学习条记)：分布式+微服务+开源框架+性能优化
本文已被CODING开源项目：【一线大厂Java口试题解析+核心总结学习条记+最新讲解视频+实战项目源码】收录
需要这份系统化的资料的朋友，可以点击这里获取
这类存储相比于传统的数据库的优势是极高的读写性能，一样平常对性能有比较高的要求的场景会使用，主要使用场景。
- 用来做分布式缓存，提升程序处理效率。
- 用来做会话数据存储
- 其他功能性特性，比如消息通信、分布式锁、布隆过滤器
- 微博的 feed 流，早期就是用了 redis 实现。（持续更新并出现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个 Feed 流）
列式数据库
=====
我们最早学习数据库，都是基于以二维表形式存储，每一行代表一条完备的数据。大部分传统的关系型数据库中，都是以行来存储数据。不外近来几年，列式存储也渐渐被广泛运用在大数据框架中。
行存储和列存储，是数据库底层数据构造的形式的区别，如图 2-6 所示，数据库表中全部列一次排成一行，以行位单位存储，再配合 B+树大概 SS-Table 作为索引，就能快速通过主键找到相应的行数据。
图 2-6
在实际应用中，大部分的操作都是以实体（Entity）为单位，也就是大部分 CRUD 操作都是针对一整行记录，假如需要生存一行数据，只需要在原来的数据后追加一行数据即可，所以数据的写入非常快。
但是对于查询来说，一个典范的查询操作需要遍历整个表，分组、排序、聚合等，对于行存储来说，如许的操作的优势就不存在了，更惨的是，分析型 SQL 大概不需要用到全部的列，仅仅只需要对某些列进行运算即可，但是那一行中和本次操作无关的列也必须要参与到数据扫描中。
比如，如图 2-7 所示，如今我想统计全部文章的总的点赞数量，作为行存储的系统，数据库会怎么操作呢？
- 首先需要把全部行的数据加载到内存
- 然后对 like_num 列做 sum 操作
图 2-7
行式存储对于 OLAP 场景而言，优势就不存在了，所以就引入了列式存储。
OLTP（on-line transaction processing）翻译为联机事件处理， OLAP（On-Line Analytical Processing）翻译为联机分析处理，从字面上来看 OLTP 是做事件处理，OLAP 是做分析处理。从对数据库操作来看，OLTP 主要是对数据的增删改，OLAP 是对数据的查询
如图 2-8 所示，列式存储是将每一列数据构造在一起，它方便对于列的操作，比如前面说的统计 like_num 之和，按列存储之后只需要一次磁盘操作就可以完成三个数据的汇总，所以非常适合 OLAP 的场景。
- 当查询语句只涉及部分列时，只需要扫描相干列
- 每一列数据都是相同类型，彼此间的关联性更大，对列数据压缩的效率较高。
但是对于 OLTP 来说不是很友爱，由于一行数据的写入需要修改多个列。
图 2-8
列式存储在大数据分析中使用非常多，比如推荐画像（蚂蚁金服的风控）、是空数据（滴滴打车的归集数据）、消息/订单（电信范畴、银行范畴）不少订单查询底层的存储。 Feeds 流（朋友圈类似的应用）等等。
图 2-9
文档型数据库
======
传统的数据库，全部信息会被分割成离散的数据字段，生存在关系型数据库中，乃至对于一些复杂的场景，还会分散在差别的表结构中。
举个例子，在一个技能论坛中，假设对于用户、文章、文章品评表的关系图如图 2-10 所示。
图 2-10
那用户点一篇文章，内里要显示该文章的创建者、文章详情、文章的品评，那么服务端要做什么呢？
- 查找文章详情
- 根据文章中的 uid 查找用户信息
- 查询该文章的全部品评列表
- 查询每个品评的创建者名字
这个过程要么就是多次数据库查询，要么就是使用一个复杂关联查询来检索，不管怎么做，都不是很方便。而文档数据库就可以解决如许的题目。
文档数据库是以文档单位，详细的文档形式有很多种，比如（XML、YAML、JSON、BSON）等，文档中存储详细的字段和值，应用可以使用这些字段进行查询和数据筛选。
一样平常情况下，文档中包罗了实体中的全部数据，比如图 2-10 的结构，我们可以直接把一篇文章的基本要素信息构建成一个完备的文档生存到文档数据库中，应用程序只需要发起一次请求就可以获取全部数据。b
Article：{
Creator:{
uid: ‘’,
username: ‘’
},
Topic: {
title: ‘’,
content: ‘’
},
Reply: [
{
replyId:,
content:‘’
},
{
replyId:,
content:‘’
}
]
}
MongoDB 是目前最盛行的 Nosql 数据库，它是一种面向集合、与模式（Schema Free）无关的文档型数据库。它的数据是以“集合”的方式进行分组，每个集合都有单独的名称并可以包罗无线数量的文档，这种集合与关系型数据库中的表类似，唯一的区别就是它并没有任何明确的 schema。
在数据库中，schema（发音 “skee-muh” 大概“skee-mah”，中文叫模式）是数据库的构造和结构，schemas 和 schemata 都可以作为复数形式。模式中包罗了 schema 对象，可以是表(table)、列(column)、数据类型(data type)、视图(view)、存储过程(stored procedures)、关系(relationships)、主键(primary key)、**外键(**foreign key)等。数据库模式可以用一个可视化的图来表示，它显示了数据库对象及其相互之间的关系
如图 2-11 所示， 将数据存储在类似 JSON 的灵活文档中，这意味着字段大概因详细文档而异，并且数据结构大概随着时间的推移而变化。
图 2-11
MongoDB 没有“数据划一性查抄”、“事件”等，不适合存储对数据事件要求较高的场景，只适合放一些非关键性数据，常见应用场景如下：
- 使用 Mongodb 对应用日志进行记录
- 存储监控数据，比如应用的埋点信息，可以直接上报存储到 mongoDB 中
- MongoDB 可以用来实现 O2O 快递应用，比如快递骑手、快递商家的信息存储在 MongoDB，然后通过 MongoDB 的地理位置查询，方便用来查询附近的商家、骑手等功能。
图形数据库
=====
图形数据库，表示以数据结构“图”作为存储的数据库。图形数据存储管理两类信息：节点信息和边缘信息。 节点表示实体，边缘表示这些实体之间的关系。 节点和边缘都可以包罗一些属性用于提供有关该节点或边缘的信息（类似于表中的列）。
边缘还可以包罗一个方向用于指示关系的性质。
图形数据存储的用途是让应用程序有效实行需遍历节点和边缘网络的查询，以及分析实体之间的关系。 如图 2-12 所示，显示了已结构化为图形的构造职员数据。
实体为员工和部分，边缘指示隶属关系以及员工地点的部分。 在此图中，边缘上的箭头表示关系的方向。
图 2-12
使用此结构可以简朴直接地实行类似于“查找 Sarah 的直接或间接下属”或“谁与 John 在同一个部分工作？”的查询。 对于包罗大量实体和关系的大型图形，可以快速实行复杂的分析。 多个图形数据库提供一种可用于高效遍历关系网络的查询语言。比如：关系、地图、网络拓扑、交通门路等场景。
NewSql
======
NewSql 也是近来几年出来的概念，想必大家或多或少都有听过，NewSql 是 Nosql 发展之后的下一代数据存储方案。
前面我们相识了 Nosql 的优势。
- 高可用性和可扩展性，自动分区，轻松扩展
- 不包管强划一性，性能大幅提升
- 没有关系模子的限定，极其灵活
但是有些优势在某些场景下不是很适合，比如不包管强划一性，对于普通应用来说没有题目，但是对于一些金融级的企业应用来说，
强划一的需求会比较高。另外，Nosql 不支持 SQL 语句，差别的 Nosql 数据库都是有自己独立的 API 来进行数据操作，相对来说比较麻烦和复杂。
所以 NewSql 出现了，简朴来说，newSQL 就是在传统关系型数据库上集成了 noSQL 强大的可扩展性，传统的 SQL 架构设计基因中是没有分布式的，而 newSQL 生于云时代，天生就是分布式架构。
NewSQL 的主要特性：
- SQL 支持，支持复杂查询和大数据分析。
- 支持 ACID 事件，支持隔离级别。
- 弹性伸缩，扩容缩容对于业务层完全透明。
- 高可用，自动容灾
商用 NewSql
- Spanner、F1：谷歌
- OceanBase：阿里
- TDSQL：腾讯
- UDDB：UCloud
总结
==
在 NoSQL 数据库刚刚被应用时，它被认为是可以更换关系型数据库的银弹，在我看来，大概由于以下几个方面的缘故原由：
- 补充了传统数据库在性能方面的不足；
- 数据库变更方便，不需要更改原先的数据结构；
- 适合互联网项目常见的大数据量的场景；
不外，这种看法是个误区，由于逐步地我们发如今业务开发的场景下还是需要使用 SQL 语句的强大的查询功能以及传统数据库事件和灵活的索引等功能，NoSQL 只能作为一些场景的增补。
使用 Redis 优化性能题目
===============
Redis 是目前用得非常多的一种 Key-Vlaue 数据库，我们先来通过一个压测数据相识一下 redis 和 mysql 的性能差距。
演示项目： springboot-redis-example
通过 jmeter 工具分别压测这个项目中的两个 url。
- http://localhost:8080/city/{id}
- http://localhost:8080/city/redis/{id}
此中，基于 mysql 访问的接口，吞吐量数据如下，qps=4735/s。
图 2-13
基于 redis 的压测数据，如图 2-14 所示。
图 2-14
可以很明显的看到，在同样的程序中，Redis 的 QPS 要比 Mysql 的多了 1000。
相识 Redis
========
08 年的时候有一个意大利西西里岛的小伙子，笔名 antirez（Salvatore Sanfilippo aka antirez），创建了一个访客信息网站 LLOOGG.COM。假如有自己做过网站的同学应该知道，
有的时候我们需要知道网站的访问情况，比如访客的 IP、操作系统、浏览器、使用的搜索关键词、地点地区、访问的网页地点等等。在国内，有很多网站提供了这个功能，比如 CNZZ，百度统计，国外也有谷歌的 Google Analytics。
也就是说，我们不消自己写代码去实现这个功能，只需要在全局的 footer 内里嵌入一段 JS 代码就行了，当页面被访问的时候，就会自动把访客的信息发送到这些网站统计的服务器，然后我们登录背景就可以检察数据了。
LLOOGG.COM 提供的就是这种功能，它可以检察最多 10000 条的最新浏览记录。如许的话，它需要为每一个网站创建一个列表（List），差别网站的访问记录进入到差别的列表。假如列表的长度超过了用户指定的长度，它需要把最早的记录删除（先进先出）。
图 2-15
当 LLOOGG.COM 的用户越来越多的时候，它需要维护的列表数量也越来越多，这种记录最新的请求和删除最早的请求的操作也越来越多。LLOOGG.COM 最初使用的数据库是 MySQL，可想而知，由于每一次记录和删除都要读写磁盘，由于数据量和并发量太大，在这种情况下无论怎么去优化数据库都不管用了。
考虑到终极限定数据库性能的瓶颈在于磁盘，所以 antirez 打算放弃磁盘，自己去实现一个具有列表结构的数据库的原型，把数据放在内存而不是磁盘，如许可以大大地提升列表的 push 和 pop 的效率。antirez 发现这种思绪确实能解决这个题目，所以用 C 语言重写了这个内存数据库，并且加上了长期化的功能，09 年，Redis 横空出世了。从最开始只支持列表的数据库，到如今支持多种数据类型，并且提供了一系列的高级特性，Redis 已经成为一个在全世界被广泛使用的开源项目。
为什么叫 REDIS 呢？它的全称是 Remote Dictionary Service，直接翻译过来是远程字典服务。
key-value 数据库使用排名
=================
对于 Redis，我们大部分时候的认识是一个缓存的组件，当然从它的发展历史我们也可以看到，它最开始并不是作为缓存使用的。只是在很多的互联网应用内里，它作为缓存发挥了最大的作用。所以下面我们来聊一下，Redis 的主要特性有哪些，我们为什么要使用它作为数据库的缓存。
大家对于缓存应该不陌生，比如我们有硬件层面的 CPU 的缓存，浏览器的缓存，手机的应用也有缓存。我们把数据缓存起来的缘故原由就是从原始位置取数据的代价太大了，放在一个临时存储起来，取回就可以快一些。
假如要相识 Redis 的特性，我们必须答复几个题目：
1、为什么要把数据放在内存中？
2、假如是用内存的数据结构作为缓存，为什么不消 HashMap 大概 Memcache？
Java核心架构进阶知识点
口试乐成其实都是必然发生的事变，由于在此之前我做足了充分的准备工作，不单单是纯粹的刷题，更多的还会去刷一些Java核心架构进阶知识点，比如：JVM、高并发、多线程、缓存、Spring相干、分布式、微服务、RPC、网络、设计模式、MQ、Redis、MySQL、设计模式、负载均衡、算法、数据结构、kafka、ZK、集群等。而这些也全被整理浓缩到了一份pdf——《Java核心架构进阶知识点整理》，全部都是精华中的精华，本着共赢的心态，好东西自然也是要分享的
内容颇多，篇幅却有限，这就不在过多的介绍了，大家可根据以上截图自行脑补
本文已被CODING开源项目：【一线大厂Java口试题解析+核心总结学习条记+最新讲解视频+实战项目源码】收录
需要这份系统化的资料的朋友，可以点击这里获取
去刷一些Java核心架构进阶知识点，比如：JVM、高并发、多线程、缓存、Spring相干、分布式、微服务、RPC、网络、设计模式、MQ、Redis、MySQL、设计模式、负载均衡、算法、数据结构、kafka、ZK、集群等。而这些也全被整理浓缩到了一份pdf——《Java核心架构进阶知识点整理》，全部都是精华中的精华，本着共赢的心态，好东西自然也是要分享的
[外链图片转存中…(img-FR9mn29P-1715271651841)]
[外链图片转存中…(img-8JOeLMpj-1715271651842)]
[外链图片转存中…(img-ntflXmaY-1715271651842)]
内容颇多，篇幅却有限，这就不在过多的介绍了，大家可根据以上截图自行脑补
本文已被CODING开源项目：【一线大厂Java口试题解析+核心总结学习条记+最新讲解视频+实战项目源码】收录
需要这份系统化的资料的朋友，可以点击这里获取
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
