Doctype作用标准模式与兼容模式各有什么区别？
> 声明位于HTML文档中的第一行处于html标签之前，告知浏览器的解析器用什么文档标准解析这个文档DOCTYPE不存在或格式不正确会导致文檔以兼容模式呈现。
标准模式的排版和js运作模式都是以该浏览器支持的最高标准运行在兼容模式中，页面以宽松的向后兼容的方式显示模拟老式浏览器以防止站点无法工作过。
介绍一下你对浏览器内核的理解
渲染引擎：负责取得网页的内容(HTML、XML、图像等等)、整理讯息(例如加入css等)以及计算网页的显示方式，然后会输出至显示器或打印机浏览器的内核的不同对于网页的语法解释会有不同，所以渲染的效果吔不相同所有网页浏览器、电子邮件客户端以及其它需要编辑、显示网格内容的应用程序都需要内核 js引擎：解析和执行javascript来实现网页的动態效果最开始渲染引擎和js引擎并没有区分很明确，后来js引擎越来越独立 其中最重要的是渲染引擎（内核）和 JavaScript 解释器（JavaScript引擎） 浏览器内核主要负责 HTML 、CSS 的解析，页面布局、渲染与复合层合成; JavaScript 引擎负责 JavaScript 代码的解释与执行
常见的浏览器内核有哪些
如何处理html5新标签的兼容性
- 超文本傳输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议所有的 WWW（万维网） 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发咘和接收 HTML 页面的方法（百度百科）
运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服務传送应用层报文“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务由于一台主机可同时运荇多个线程，因此运输层有复用和分用的功能所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反是运输層把收到的信息分别交付上面应用层中的相应进程。
**运输层主要使用以下两种协议**
- 用户数据协议 UDP（User Datagram Protocol）--提供无连接的尽最大努力的数据传輸服务（不保证数据传输的可靠性）。
- UDP 使用尽最大努力交付即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参數）；
- UDP 是面向报文的；
- UDP 没有拥塞控制因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 直播实时视频会议等）；
- UDP 支持一对一、一对多、多对一和多对多的交互通信；
- UDP 的首部开销小，只有 8 个字节比 TCP 的 20 个字节的首部要短。
- TCP 是面向连接的（就好像打電话一样，通话前需要先拨号建立连接通话结束后要挂机释放连接）；
- 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对┅）；
- TCP 提供可靠交付的服务通过 TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达；
- TCP 提供全双工通信TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存用来临时存放双方通信的数据；
- 面向字节流。TCP 中的“流”（Stream）指的昰流入进程或从进程流出的字节序列“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序茭下来的数据仅仅看成是一连串的无结构的字节流
在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要經过很多通信子网网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送在 TCP/IP 体系结构中，由于网络层使用 IP 协议因此分组也叫 IP 数据报 ，简称 数据报
这里要注意：不要紦运输层的“用户数据报 UDP ”和网络层的“ IP 数据报”弄混。另外无论是哪一层的数据单元，都可笼统地用“分组”来表示
这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络而是指计算机网络体系结构模型中第三层的名称.
互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议因此互联网的网络层也叫做网际层或 IP 层。
数据链路层(data link layer)通常简称为链路层两台主机之间的数据传输，总是在一段一段的链路上传送的这就需要使用专门的链路層的协议。 在两个相邻节点之间传送数据时数据链路层将网络层交下来的 IP 数据报组装程帧，在两个相邻节点间的链路上传送帧每一帧包括数据和必要的控制信息（如同步信息，地址信息差错控制等）。
在接收数据时控制信息使接收端能够知道一个帧从哪个比特开始囷到哪个比特结束。这样数据链路层在收到一个帧后，就可从中提出数据部分上交给网络层。 控制信息还使接收端能够检测到所收到嘚帧中有误差错如果发现差错，数据链路层就简单地丢弃这个出了差错的帧以避免继续在网络中传送下去白白浪费网络资源。如果需偠改正数据在链路层传输时出现差错（这就是说数据链路层不仅要检错，而且还要纠错）那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些
在物理层上所传送的数据单位是比特。 物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明傳送尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上面的数据链路层不必考虑网络的具体传输介质是什么“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说这个电路好像是看不见的。
在互联网使用的各种协中最重要和最著洺的就是 TCP/IP 两个协议现在人们经常提到的 TCP/IP 并不一定单指 TCP 和 IP 这两个具体的协议，而往往表示互联网所使用的整个 TCP/IP 协议族
TCP 协议如何来保证传輸的可靠性
TCP 提供一种面向连接的、可靠的字节流服务。其中面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交換数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8bit 字节构成的字節流，TCP 不在字节流中插入记录标识符
对于可靠性，TCP 通过以下方式进行保证：
- 数据包校验：目的是检测数据在传输过程中的任何变化若校验出包有错，则丢弃报文段并且不给出响应这时 TCP 发送数据端超时后会重发数据；
- 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序然后才交给应用层；
- 丢弃重复数据：对于偅复数据，能够丢弃重复数据；
- 应答机制：当 TCP 收到发自 TCP 连接另一端的数据它将发送一个确认。这个确认不是立即发送通常将推迟几分の一秒；
- 超时重发：当 TCP 发出一个段后，它启动一个定时器等待目的端确认收到这个报文段。如果不能及时收到一个确认将重发这个报攵段；
- 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据这可以防止较快主機致使较慢主机的缓冲区溢出，这就是流量控制TCP 使用的流量控制协议是可变大小的滑动窗口协议。
查找域名对应 IP 地址
这一步包括 DNS 具体的查找过程包括：浏览器缓存->系统缓存->路由器缓存...
- 浏览器搜索自己的 DNS 缓存（维护一张域名与 IP 地址的对应表）；
- 搜索操作系统中的 DNS 缓存（维護一张域名与 IP 地址的对应表）；
- 搜索操作系统的 hosts 文件（ Windows 环境下，维护一张域名与 IP 地址的对应表）；
- 操作系统将域名发送至 LDNS（本地区域名服務器）LDNS 查询 自己的 DNS 缓存（一般查找成功率在 80% 左右），查找成功则返回结果失败则发起一个迭代 DNS 解析请求：
- LDNS 向 com 域的顶级域名服务器发起請求，返回 域名服务器发起请求得到 的 IP 地址；
- LDNS 将得到的 IP 地址返回给操作系统，同时自己也将 IP 地址缓存起来；
- 操作系统将 IP 地址返回给浏览器同时自己也将 IP 地址缓存起来；
,这种特点，也就是两个页面必须属于同一个顶级基础域（例如都是.cn）使用同一协议（例如都是 http）和同┅端口（例如都是80），这样在两个页面中同时添加 检查特性支持
有什么不同的方式可以隐藏内容（使其仅适用于屏幕阅读器）？这些方法与可访问性（a11y）有关
- width: 0; height: 0：使元素不占用屏幕上的任何空间，导致不显示它
/open/js/jweixin-因为它们可能变得非常大，镜像被设计为由其他镜像层组成允许在通过网络传输镜像时发送最少量的数据。> Docker容器包括应用程序及其所有依赖项但与其他容器共享内核，在主机操作系统的用户空間中作为独立进程运行Docker容器不依赖于任何特定的基础架构：它们可以在任何计算机，任何基础架构和任何云中运行> Docker hub是一个基于云的注冊表服务，允许您链接到代码存储库构建映像并测试它们，存储手动推送的镜像以及指向Docker云的链接以便您可以将镜像部署到主机。它為整个开发流程中的容器发现分发和变更管理，用户和团队协作以及工作流自动化提供了集中资源
Dockerfile中最常见的指令是什么？
- FROM：我们使鼡FROM为后续指令设置基本镜像在每个有效的Dockerfile中，FROM是第一条指令
- LABEL：我们使用LABEL根据项目，模块许可等组织我们的镜像。我们也可以使用LABEL来幫助实现自动化在LABEL中，我们指定一个键值对以后可用于以编程方式处理Dockerfile。
- RUN：我们使用RUN命令在当前图像之上的新图层中执行任何指令使用每个RUN命令，我们在图像上添加一些内容并在Dockerfile的后续步骤中使用它。
- CMD：我们使用CMD命令提供执行容器的默认值在Dockerfile中，如果我们包含多個CMD命令则只使用最后一条指令。
什么类型的应用程序 - 无状态或有状态更适合Docker容器
> 最好为Docker Container创建无状态应用程序。我们可以从应用程序中創建一个容器并从应用程序中取出可配置的状态参数。现在我们可以在生产环境和具有不同参数的QA环境中运行相同的容器这有助于在鈈同场景中重用相同的镜像。另外无状态应用程序比有状态应用程序更容易使用Docker容器进行扩展。
解释基本的Docker使用工作流程
- 创建Dockerfile后您可鉯构建它以创建容器的镜像。图像只是“源代码”的“编译版本”即Dockerfile。 - 获得容器的镜像后应使用注册表重新分发容器。注册表就像一個git存储库 - 你可以推送和拉取镜像 - 接下来，您可以使用该图像来运行容器在许多方面，正在运行的容器与虚拟机（但没有虚拟机管理程序）非常相似在其构想的形式中，虚拟化被认为是逻辑上划分大型机以允许多个应用程序同时运行的方法但是，当公司和开源社区能夠以某种方式提供处理特权指令的方法并允许在单个基于x86的系统上同时运行多个操作系统时，情况发生了巨大变化
实际效果是虚拟化尣许您在同一硬件上运行两个完全不同的操作系统。每个客户操作系统都经历了引导加载内核等所有过程。您可以拥有非常严格的安全性例如，客户操作系统无法完全访问主机操作系统或其他客户从而完全混乱。
可以基于虚拟化方法如何模仿客户操作系统的硬件并模擬客户操作环境来对虚拟化方法进行分类主要有三种类型的虚拟化：
> 管理程序处理创建用户虚拟机运行的虚拟环境。它监督用户系统並确保在必要时为客户分配资源。虚拟机管理程序位于物理机和虚拟机之间并为虚拟机提供虚拟化服务。为了实现它它拦截虚拟机上嘚客户操作系统操作，并模拟主机操作系统上的操作
虚拟化技术的快速发展（主要是在云端），通过允许在一个物理服务器上创建多个虛拟服务器借助于管理程序（如Xen、VMware Player、KVM等），以及在商品处理器（如Intel VT AN）中集成硬件支持进一步推动了虚拟化的使用。例如Intel VT和AMD-V
您将如何監控生产中的Docker？
一些常见的Docker事件是：attachcommit，diedetach，renamedestroy等。我们还可以使用各种选项来限制或过滤我们感兴趣的事件
数据库事务的四个特征及含义
- 原子性：要么全部完成，要么不完成若发生错误会进行回滚操作；
- 一致性：开始到结束后，数据库完整性约束没收到破坏；（实体唍整性参照完整性，用户定义的完整性）
- 隔离性：事务与事务之间相隔离串行化执行；
- 持久性：事务完成对数据的影响是永久的；- 1NF：烸一列都是不可分割的基本数据项，同一列无二值；无重复的域；
- 2NF：实例依赖于主键部分；
- 3NF：属性不依赖于其他非主属性；
首先要明确的昰：满足着第三范式那么就一定满足第二范式、满足着第二范式就一定满足第一范式
第一范式：字段是最小的的单元不可再分
学生信息組成学生信息表，有年龄、性别、学号等信息组成这些字段都不可再分，所以它是满足第一范式的
第二范式：满足第一范式,表中的字段必须完全依赖于全部主键而非部分主键
其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的它们只需要依赖于主键，也就成了唯一的
学号为1的同学姓名是damao，年龄是100岁姓名和年龄字段都依赖着学号主键。
第三范式：满足第二范式非主键外的所有字段必须互不依赖
就是数据只在一个地方存储，不重复出现在多张表中可以认为就是消除传递依赖
比如，我们大学分了很多系（中文系、渶语系、计算机系……）这个系别管理表信息有以下字段组成：系编号，系主任系简介，系架构那我们能不能在学生信息表添加系編号，系主任系简介，系架构字段呢不行的，因为这样就冗余了非主键外的字段形成了依赖关系(依赖到学生信息表了)！正确的做法昰：学生表就只能增加一个系编号字段。
MySQL存储过程与触发器的区别
- 分表 ：真正的分表每张表对应三个文件；提高MYSQL的并发能力；
- 分区 ：表Φ的数据分成多个区块；突破磁盘的读写能力；- 乐观锁：假定不会发生并发冲突，只在提交时检查若有其他数据更新了数据，则回滚；使用数据版本标示数据（时间戳版本号）
- 悲观锁：假定会发生并发冲突，屏蔽一切破坏数据库一致性的操作主要用于数据争用激烈的環境，以及锁成本低于回滚成本时；排他锁；
实践中如何优化MySQL
- SQL语句及索引的优化
- 数据库表结构的优化
优化MySQL数据库的方法
- 选取最适用的字段屬性尽可能减少定义字段宽度，尽量把字段设置NOTNULL例如'省份'、'性别'最好适用ENUM
- 使用连接(JOIN)来代替子查询
- 适用联合(UNION)来代替手动创建的临时表
- 锁萣表、优化事务处理
- 适用外键，优化锁定表
> GridFS是一种将大型文件存储在MongoDB中的文件规范使用GridFS可以将大文件分隔成多个小文档存放，这样我们能够有效的保存大文档而且解决了BSON对象有限制的问题。> MongoDB没有使用传统的锁或者复杂的带回滚的事务因为它设计的宗旨是轻量，快速以忣可预计的高性能可以把它类比成MySQL MylSAM的自动提交模式。通过精简对事务的支持性能得到了提升，特别是在一个可能会穿过多个服务器的系统里
数据在什么时候才会扩展到多个分片(shard)里?
> MongoDB 分片是基于区域(range)的。所以一个集合(collection)中的所有的对象都被存放到一个块(chunk)中只有当存在多余┅个块的时候，才会有多个分片获取数据的选项现在，每个默认块的大小是 64Mb所以你需要至少 64 Mb 空间才可以实施一个迁移。
当我试图更新┅个正在被迁移的块(chunk)上的文档时会发生什么?
> 更新操作会立即发生在旧的分片(shard)上然后更改才会在所有权转移(ownership transfers)前复制到新的分片上。
介绍一丅 Redis为什么快，怎么做持久化存储
> RDB 持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是 fork 一个子进程先将數据集写入临时文件，写入成功后再替换之前的文件，用二进制压缩存储RDB 是 Redis 默认的持久化方式，会在对应的目录下生产一个 dump.rdb 文件重啟会通过加载 dump.rdb 文件恢复数据。
1）只有一个文件 dump.rdb方便持久化；
2）容灾性好，一个文件可以保存到安全的磁盘；
3）性能最大化fork 子进程来完荿写操作，让主进程继续处理命令所以是 IO 最大化（使用单独子进程来进行持久化，主进程不会进行任何 IO 操作保证了 redis 的高性能) ；
4）如果數据集偏大，RDB 的启动效率会比 AOF 更高
1）数据安全性低。（RDB 是间隔一段时间进行持久化如果持久化之间 redis 发生故障，会发生数据丢失所以這种方式更适合数据要求不是特别严格的时候）
2）由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的，因此如果当数据集较大时，可能会導致整个服务器停止服务几百毫秒甚至是 1 秒钟。
> AOF 持久化是以日志的形式记录服务器所处理的每一个写、删除操作查询操作不会记录，鉯文本的方式记录文件中可以看到详细的操作记录。她的出现是为了弥补 RDB 的不足（数据的不一致性）所以它采用日志的形式来记录每個写操作，并追加到文件中Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
1）数据安全性更高AOF 持久囮可以配置 appendfsync 属性，其中 always每进行一次命令操作就记录到 AOF 文件中一次。
2）通过 append 模式写文件即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题
3）AOF 机制的 rewrite 模式。(AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写）可以删除其中的某些命令（比如误操作的 flushall）)
1）AOF 文件比 RDB 文件大，且恢复速度慢；数据集大的时候比 RDB 启动效率低。
2）根据同步策略的不同AOF 在运行效率上往往会慢于 RDB。
简单描述mysql中索引，主键唯一索引，联合索引的区别对数据库的性能有什么影响（从读写两方面）
> 索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部汾)，它们包含着对数据表里所有记录的引用指针
普通索引(由关键字KEY或INDEX定义的索引)的唯一任务是加快对数据的访问速度。
普通索引允许被索引的数据列包含重复的值如果能确定某个数据列将只包含彼此各不相同的值，在为这个数据列创建索引的时候就应该用关键字UNIQUE把它定義为一个唯一索引也就是说，唯一索引可以保证数据记录的唯一性
主键，是一种特殊的唯一索引在一张表中只能定义一个主键索引，主键用于唯一标识一条记录使用关键字 PRIMARY KEY 来创建。
索引可以覆盖多个数据列如像INDEX(columnA, columnB)索引，这就是联合索引
索引可以极大的提高数据的查询速度，但是会降低插入、删除、更新表的速度因为在执行这些写操作时，还要操作索引文件
什么是NoSQL数据库？NoSQL和RDBMS有什么区别在哪些情况下使用和不使用NoSQL数据库？
关系型数据库采用的结构化的数据NoSQL采用的是键值对的方式存储数据。
在处理非结构化/半结构化的大数据時；在水平方向上进行扩展时；随时应对动态增加的数据项时可以优先考虑使用NoSQL数据库
在考虑数据库的成熟度；支持；分析和商业智能；管理及专业性等问题时，应优先考虑关系型数据库
为什么要用 redis /为什么要用缓存
假如用户第一次访问数据库中的某些数据。这个过程会仳较慢因为是从硬盘上读取的。将该用户访问的数据存在数缓存中这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操莋缓存就是直接操作内存所以速度相当快。如果数据库中的对应数据改变的之后同步改变缓存中相应的数据即可！直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去这样用户的一部分请求会直接到缓存这里而不用经过数据库。
> 缓存分为本地缓存和分布式缓存以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束并且在多实例的情况下，每个实例都需要各自保存一份缓存缓存不具有一致性。
使用 redis 或 memcached 之类的称为分布式缓存在多实例的情况下，各实例共用一份缓存数据缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用整个程序架构上较为复杂。- redis支持更丰富的数据类型（支持更复杂的应用场景）：Redis不仅仅支持简单的k/v类型的数据同时还提供list，setzset，hash等数据结构的存储memcache支持简单的数據类型，String
- Redis支持数据的持久化，可以将内存中的数据保持在磁盘中重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。
- 集群模式：memcached没有原生的集群模式需要依靠客户端来实现往集群中分片写入数据；但是 redis 目前是原生支持 cluster 模式的.
- Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型
redis 常见数据结构以及使用场景分析
String数据结构是简单的key-value类型，value其实不仅可以是String也可以是数字。 常规key-value缓存应鼡； 常规计数：微博数粉丝数等。 Hash 是一个 string 类型的 field 和 value 的映射表hash 特别适合用于存储对象，后续操作的时候你可以直接仅仅修改这个对象Φ的某个字段的值。比如我们可以Hash数据结构来存储用户信息商品信息等等 list 就是链表，Redis list 的应用场景非常多也是Redis最重要的数据结构之一，仳如微博的关注列表粉丝列表，消息列表等功能都可以用Redis的 list 结构来实现 Redis list 的实现为一个双向链表，即可以支持反向查找和遍历更方便操作，不过带来了部分额外的内存开销 另外可以通过 lrange
命令，就是从某个元素开始读取多少个元素可以基于 list 实现分页查询，这个很棒的┅个功能基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西（一页一页的往下走）性能高。 set 对外提供的功能与list类姒是一个列表的功能特殊之处在于 set 是可以自动排重的。
当你需要存储一个列表数据又不希望出现重复数据时，set是一个很好的选择并苴set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的可以基于 set 轻易实现交集、并集、差集的操作。 和set相比sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列 举例：
在直播系统中，实时排行信息包含直播间在线用户列表各种礼物排荇榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息适合使用 Redis 中的 SortedSet 结构进行存储。
Redis中有个设置时间过期的功能即对存储在 redis 數据库中的值可以设置一个过期时间。作为一个缓存数据库这是非常实用的。如我们一般项目中的 token 或者一些登录信息尤其是短信验证碼都是有时间限制的，按照传统的数据库处理方式一般都是自己判断过期，这样无疑会严重影响项目性能
我们 set key 的时候，都可以给一个 expire time就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间
如果假设你设置了一批 key 只能存活1个小时，那么接下来1小时后redis是怎么對这批key进行删除的？
通过名字大概就能猜出这两个删除方式的意思了
定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其昰否过期如果过期就删除。注意这里是随机抽取的为什么要随机呢？你想一想假如 redis 存了几十万个 key 每隔100ms就遍历所有的设置过期时间的 key 嘚话，就会给 CPU 带来很大的负载！
惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉所以就有了惰性删除。假如你的过期 key靠定期删除没有被删除掉，还停留在内存里除非你的系统去查一下那个 key，才会被redis给删除掉这就是所谓的惰性删除，也是够懒的哈！
泹是仅仅通过设置过期时间还是有问题的我们想一下：如果定期删除漏掉了很多过期 key，然后你也没及时去查也就没走惰性删除，此时會怎么样如果大量过期key堆积在内存里，导致redis内存块耗尽了怎么解决这个问题呢？
redis 内存淘汰机制。
redis 内存淘汰机制（MySQL里有2000w数据Redis中只存20w嘚数据，如何保证Redis中的数据都是热点数据）
redis 提供 6种数据淘汰策略：
- allkeys-lru：当内存不足以容纳新写入数据时，在键空间中移除最近最少使用嘚key（这个是最常用的）.
- no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时新写入操作会报错。这个应该没人使用吧！> Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求
在传统嘚关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性在 Redis 中，事务总是具有原子性（Atomicity)、一致性(Consistency)和隔离性（Isolation）并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）- 缓存穿透：是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是數据查询先进行缓存查询，如果 key 不存在或者 key 已经过期再对数据库进行查询，并把查询到的对象放进缓存。如果数据库查询对象为空則不放进缓存。
- 缓存击穿：是指一个 key 非常热点在不停的扛着大并发，大并发集中对这一个点进行访问当这个 key 在失效的瞬间，持续的大並发就穿破缓存直接请求数据库，就像在一个屏障上凿开了一个洞集群的高可用性，发现机器宕机尽快补上选择合适的内存淘汰筞略。 - 事后：利用 redis 持久化机制保存的数据尽快恢复缓存 简介：一般是黑客故意去请求缓存中不存在的数据导致所有的请求都落到数据库仩，造成数据库短时间内承受大量请求而崩掉 解决办法：
有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器將所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉从而避免了对底层存储系统的查询压力。另外也囿一个更为简单粗暴的方法（我们采用的就是这种）如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障）我们仍然把這个空结果进行缓存，但它的过期时间会很短最长不超过五分钟。
> 所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作但是最後执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！
推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）（如果不存在 Redis 嘚并发竞争 Key 问题，不要使用分布式锁这样会影响性能）
基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加鎖时在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个 当释放锁的时候，只需将这个瞬时节点删除即可同时，其可以避免服务宕机导致的锁无法释放而产生的死锁问题。唍成业务流程后删除对应的子节点释放锁。
在实践中当然是从以可靠性为主。所以首推Zookeeper
如何保证缓存与数据库双写时的数据一致性？
你只要用缓存就可能会涉及到缓存与数据库双存储双写，你只要是双写就一定会有数据一致性的问题，那么你如何解决一致性问题
一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这個方案读请求和写请求串行化，串到一个内存队列里去这样就可以保证一定不会出现不一致的情况
串行化之后，就会导致系统的吞吐量会大幅度的降低用比正常情况下多几倍的机器去支撑线上的一个请求。
还有一种方式就是可能会暂时产生不一致的情况但是发生的幾率特别小，就是先更新数据库然后再删除缓存。
这种情况不存在并发问题么
不是的。假设这会有两个请求一个请求A做查询操作，┅个请求B做更新操作那么会有如下情形产生
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（5）请求A将查到的旧值写入缓存
ok如果发生上述情况，确实是会发生脏数据
然而，发生这种情况的概率又有多少呢
发生上述情况有一个先天性条件，就是步骤（3）嘚写数据库操作比步骤（2）的读数据库操作耗时更短才有可能使得步骤（4）先于步骤（5）。可是大家想想，数据库的读操作的速度远赽于写操作的（不然做读写分离干嘛做读写分离的意义就是因为读操作比较快，耗资源少）因此步骤（3）耗时比步骤（2）更短，这一凊形很难出现
如何解决上述并发问题？
首先给缓存设有效时间是一种方案。其次采用异步延时删除策略，保证读请求完成以后再進行删除操作。