大部分知识点来源于该博主——骆昊
知识点来源于网络,知道的可以在评论区贴上来源喔
《零散知识点总结1》
该文章涉及:Dubbo、HTTP和HTTPS、Mybatis、Hibernate、 Zookeeper、Kafka、Elasticsearch、Redis
《零散知识点总结2》
该文章涉及:MySQL、Java并发编程、Java IO 和 NIO、JUnit单元测试
《零散知识点总结3》
该文章涉及 :Java Web、sprig的全家桶(spring、SpringMVC、springboot、springcloud)、微服务
《零散知识点总结4》
该文章涉及:JVM和GC、Linux、Git、RabbitMQ
《零散知识点总结5》
该文章涉及:多线程、反射、对象拷贝、异常、容器
Dobbo:阿里巴巴公司开源的一个高性能优秀的(分布式)服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 [1] Spring框架无缝集成。
三大核心能力:
面向接口的远程方法调用,(RPC:远程过程调用)
智能容错和负载均衡,
以及服务自动注册和发现。
Dubbo提供的注册中心有如下几种类型可供选择:
Multicast注册中心
Zookeeper注册中心(推荐)
Redis注册中心(缓存推荐)
Simple注册中心
Dubbo优缺点
优点:
1.透明化的远程方法调用- 像调用本地方法一样调用远程方法;只需简单配置,没有任何API侵入。
2.软负载均衡及容错机制-可在内网替代nginx lvs等硬件负载均衡器。
3.服务注册中心自动注册 & 配置管理-不需要写死服务提供者地址,注册中心基于接口名自动查询提供者ip。
使用类似zookeeper等分布式协调服务作为服务注册中心,可以将绝大部分项目配置移入zookeeper集群。
4.服务接口监控与治理-Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能,针对不同应用的不同接口,可以进行 多版本,多协议,多注册中心管理。
缺点:只支持JAVA语言
Zookeeper是一个分布式的服务框架,是树型的目录服务的数据存储,能做到集群管理数据 ,这里能很好的作为Dubbo服务的注册中心。
Dubbo能与Zookeeper做到集群部署,当提供者出现断电等异常停机时,Zookeeper注册中心能自动删除提供者信息,
当提供者重启时,能自动恢复注册数据,以及订阅请求。
Dubbo 的整体架构设计有哪些分层?
接口服务层(Service):该层与业务逻辑相关,根据 provider (服务提供者)和 consumer (服务消费者)的业务设计对应的接口和实现
配置层(Config):对外配置接口,以 ServiceConfig 和 ReferenceConfig 为中心
服务代理层(Proxy):服务接口透明代理,生成服务的客户端 Stub 和 服务端的 Skeleton,以 ServiceProxy 为中心,扩展接口为ProxyFactory
服务注册层(Registry):封装服务地址的注册和发现,以服务 URL 为中心,扩展接口为 RegistryFactory、Registry、RegistryService
路由层(Cluster):封装多个提供者的路由和负载均衡,并桥接注册中心,以Invoker 为中心,扩展接口为 Cluster、Directory、Router 和 LoadBlancce
监控层(Monitor):RPC 调用次数和调用时间监控,以 Statistics 为中心,扩展接口为 MonitorFactory、Monitor 和 MonitorService
远程调用层(Protocal):封装 RPC 调用,以 Invocation 和 Result 为中心,扩展接口为 Protocal、Invoker 和 Exporter
信息交换层(Exchange):封装请求响应模式,同步转异步。以 Request 和Response 为中心,扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer
网络传输层(Transport):抽象 mina 和 netty 为统一接口,以 Message 为中心,扩展接口为 Channel、Transporter、Client、Server 和 Codec
数据序列化层(Serialize):可复用的一些工具,扩展接口为 Serialization、ObjectInput、ObjectOutput 和 ThreadPool
默认使用的是什么通信框架,还有别的选择吗?
默认推荐使用netty 框架,还有 mina
服务调用是阻塞的吗?
默认是阻塞的,可以异步调用,没有返回值的可以这么做。Dubbo 是基于 NIO 的非阻塞实现并行调用,客户端不需要启动多线程即可完成
并行调用多个远程服务,相对多线程开销较小,异步调用会返回一个 Future 对象。
一般使用什么注册中心?还有别的选择吗?
推荐使用 Zookeeper 作为注册中心,还有 Redis、Multicast、Simple 注册中心,但不推荐。
默认使用什么序列化框架,你知道的还有哪些?
推荐使用 Hessian 序列化,还有 Duddo、FastJson、Java 自带序列化。
服务提供者能实现失效踢出是什么原理?
服务失效踢出基于 zookeeper 的临时节点原理。
服务上线怎么不影响旧版本?
采用多版本开发,不影响旧版本。
服务上线怎么兼容旧版本?
可以用版本号(version)过渡,多个不同版本的服务注册到注册中心,版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。
如何解决服务调用链过长的问题?
可以结合 zipkin 实现分布式服务追踪。
说说核心的配置有哪些?
配置 | 配置说明 |
---|---|
dubbo:service | 服务配置 |
dubbo:reference | 引用配置 |
dubbo:protocol | 协议配置 |
dubbo:application | 应用配置 |
dubbo:module | 模块配置 |
dubbo:registry | 注册中心配置 |
dubbo:monitor | 监控中心配置 |
dubbo:provider | 提供方配置 |
dubbo:consumer | 消费方 配置 |
dubbo:method | 方法配置 |
dubbo:argument | 参数配置 |
dubbo推荐用什么协议?
dubbo://(推荐)、 rmi://、 hessian://、 http://、 webservice://、 thrift://、 memcached://、 redis://、rest://
同一个服务多个注册的情况下可以直连某一个服务吗?
可以点对点直连,修改配置即可,也可以通过 telnet 直接某个服务。
服务注册与发现的流程图
dubbo容错方案
集群容错方案 | 说明 |
---|---|
Failover Cluster | 失败自动切换,自动重试其它服务器(默认) |
Failfast Cluster | 快速失败,立即报错,只发起一次调用 |
Failsafe Cluster | 失败安全,出现异常时,直接忽略 |
Failback Cluster | 失败自动恢复,记录失败请求,定时重发 |
Forking Cluster | 并行调用多个服务器,只要一个成功即返回 |
Broadcast Cluster | 广播逐个调用所有提供者,任意一个报错则报错 |
Dubbo 支持服务降级吗?失败重试怎么做?
可以通过 dubbo:reference
中设置 mock="return null"
。mock 的值也可以修改为 true,然后再跟接口同一个路径下实现一个 Mock 类,命名规则是 “接口名称+Mock” 后缀。然后在 Mock 类里实现自己的降级逻辑
Dubbo 使用过程中都遇到了些什么问题?
在注册中心找不到对应的服务,检查 service 实现类是否添加了@service 注解无法连接到注册中心,检查配置文件中的对应的测试 ip 是否正确
Dubbo 配置文件是如何加载到 Spring 中的?
Spring 容器在启动的时候,会读取到 Spring 默认的一些 schema 以及 Dubbo 自定义的 schema,每个 schema 都会对应一个自己的 NamespaceHandler,NamespaceHandler 里面通过 BeanDefinitionParser 来解析配置信息并转化为需要加载的 bean 对象!
Dubbo 支持分布式事务吗?
目前暂时不支持,可与通过 tcc-transaction 框架实现,介绍:tcc-transaction 是开源的 TCC 补偿性分布式事务框架
Git 地址
TCC-Transaction 通过 Dubbo 隐式传参的功能,避免自己对业务代码的入侵。
Dubbo 可以对结果进行缓存吗?
可以(声明式缓存,提高数据访问速度,减少用户加缓存的工作量)
其实比普通的配置文件就多了一个标签 cache="true
Dubbo 必须依赖的包有哪些?
Dubbo 必须依赖 JDK,其他为可选。
Dubbo telnet 命令能做什么?
dubbo 服务发布之后,我们可以利用 telnet 命令进行调试、管理。Dubbo2.0.5 以上版本服务提供端口支持 telnet 命令
连接服务:telnet localhost 20880 //键入回车进入 Dubbo 命令模式。
查看服务列表
dubbo>ls
com.test.TestService
dubbo>ls com.test.TestService
create
delete
query
ls (list services and methods)
ls : 显示服务列表。
ls -l : 显示服务详细信息列表。
ls XxxService:显示服务的方法列表。
ls -l XxxService:显示服务的方法详细信息列表
Dubbo 如何优雅停机?
Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的,所以如果使用kill -9 PID
等强制关闭指令,是不会执行优雅停机的,只有通过 kill PID
时,才会执行。
Dubbo 和 Dubbox 之间的区别?
Dubbox 是继 Dubbo 停止维护后,当当网基于 Dubbo 做的一个扩展项目,如加了服务可 Restful 调用,更新了开源组件等。
两者之间本质上没什么区别,因为dubbox是dubbo扩展出来的,扩展以下的功能:
支持REST风格远程调用(HTTP + JSON/XML);
支持基于Kryo和FST的Java高效序列化实现;
支持基于Jackson的JSON序列化;
支持基于嵌入式Tomcat的HTTP remoting体系;
升级Spring至3.x;
升级ZooKeeper客户端;
支持完全基于Java代码的Dubbo配置;
Dubbo 和 Spring Cloud 的区别?
根据微服务架构在各方面的要素,看看 Spring Cloud 和 Dubbo 都提供了哪些支持。
Dubbo | Spring Cloud | |
---|---|---|
服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
服务调用方式 | RPC | REST API |
服务网关 | 无 | Spring Cloud Netflix Zuul |
断路器 | 不完善 | Spring Cloud Netflix Hystrix |
分布式配置 | 无 | Spring Cloud Config |
服务跟踪 | 无 | Spring Cloud Sleuth |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream |
批量任务 | 无 | Spring Cloud Task |
…… | …… | …… |
使用 Dubbo 构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;
而 Spring Cloud 就像品牌机,在Spring Source 的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解
你还了解别的分布式框架吗?
别的还有 spring 的 spring cloud,facebook 的 thrift,twitter 的 finagle 等
Double、decimal和float的区别?
Double、decimal和float都可以表示小数,float是单精度,double是双精度,decimal是数字型,它们所占的内存空间不一样,表示的位数也不一样。
在精度上,double比float精确,但是依然会存在精度损失的问题,且不会报任何错误和异常;在占内存和处理速度上,float要快得多,因此如果涉及到小数计算的话,我们会建议用decimal型
总而言之,自己看情况来使用吧
HTTP和HTTPS
跨域:协议、域名(子/主)端口号任意一个不同,相互请求资源都可以称为跨域。
域名地址组成----例如: http://www.abc.com:8080/scripts/jquery.js
http://(协议);
www(子域名);
abc.com(主域名);
8080(端口号);
scripts/jquery.js(请求资源地址);
HTTP:是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。(最广泛、明文传输安全性较差、端口80)
HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。(要到ca申请证书,一般免费证书较少,因而需要一定费用、是由http+SSL加密传输的,身份认证的网络协议,安全性较高、端口443)
HTTPS协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。
TCP和 UDP的区别,TCP为什么是三次握手?
TCP和 UDP的区别:TCP是双工协议,比UDP更可靠,效率也更高;
tcp(传输控制协议) 和 udp (用户数据报协议)是 OSI(开放式系统互联参考模型) 模型中的运输层中的协议。tcp 提供可靠的通信传输,而 udp 则常被用于让广播和细节控制交给应用的通信传输。
两者的区别大致如下:
TCP为什么是三次握手:为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次握手,为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次握手。详细的三次握手
TCP为什么不可以两次握手?
如果采用两次握手,那么只要服务器发出确认数据包就会建立连接,但由于客户端此时并未响应服务器端的请求,那此时服务器端就会一直在等待客户端,这样服务器端就白白浪费了一定的资源。若采用三次握手,服务器端没有收到来自客户端的再此确认,则就会知道客户端并没有要求建立请求,就不会浪费服务器的资源。
说一下 tcp 粘包是怎么产生的?
tcp 粘包可能发生在发送端或者接收端,分别来看两端各种产生粘包的原因:
http 和RPC 的区别
RPC两大核心:通讯,序列化
什么是RPC,推荐阅读 https://www.jianshu.com/p/2accc2840a1b
http 和RPC 都是很常见的服务远程调用的方式,那么它们之间有什么区别呢?
https://www.cnblogs.com/helloworldmybokeyuan/p/11626833.html
RPC:Remote Produce Call远程过程调用,类似的还有RMI(Remote Methods Invoke 远程方法调用,是JAVA中的概念,是JAVA十三大技术之一)。自定义数据格式,基于原生TCP通信,速度快,效率高。早期的webservice,现在热门的dubbo,都是RPC的典型
RPC的框架:webservie(cxf)、dubbo
RMI的框架:hessian
Http:(前面也有提到)http其实是一种网络传输协议,基于TCP,规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。
现在热门的Rest风格,就可以通过http协议来实现。
http的实现技术:HttpClient
相同点:底层通讯都是基于socket,都可以实现远程调用,都可以实现服务调用服务
不同点:
RPC:框架有:dubbo、cxf、(RMI远程方法调用)Hessian
当使用RPC框架实现服务间调用的时候,要求服务提供方和服务消费方都必须使用统一的RPC框架,要么都dubbo,要么都cxf
跨操作系统在同一编程语言内使用
优势:调用快、处理快
http:框架有:httpClient
当使用http进行服务间调用的时候,无需关注服务提供方使用的编程语言,也无需关注服务消费方使用的编程语言,服务提供方只需要提供restful风格的接口,服务消费方,按照restful的原则,请求服务,即可
跨系统跨编程语言的远程调用框架
优势:通用性强
总结:对比RPC和http的区别
1 RPC要求服务提供方和服务调用方都需要使用相同的技术,要么都hessian,要么dubbo而http无需关注语言的实现,只需要遵循rest规范
2 RPC的开发要求较多,像Hessian框架还需要服务器提供完整的接口代码(包名.类名.方法名必须完全一致),否则客户端无法运行
3 Hessian只支持POST请求
4 Hessian只支持JAVA语言
vue.js跟thymeleaf 的区别
首先说,这两种技术在本质上属于不同类型的产品。Vue.js属于前端框架,thymeleaf属于模板引擎。
虽然它们可以实现相同的功能(如列表),但它们的工作流程是不同的:vue.Js通过异步请求数据,后端向前端返回json,
前端通过列表呈现vue指令循环。Thymeleaf是在后端实现页面的渲染,将页面直接呈现给浏览器显示。
一般来说,后台管理我们会使用前端框架,而网站前台的部分有些页面会用thymeleaf。
有两个原因:
(1) 因为使用vuejs进行异步请求,打开页面看到的信息显示会出现延迟,而使用thymeleaf,页面的信息就会很快看到。
(2)异步加载数据不会被搜索引擎抓取。所以当我们希望数据被搜索引擎收录,就需要使用thymeleaf这样的模板引擎。
Mybatis学习:
认识mybatis:持久化
第一个mybatis程序
CRUD
mybatis 配置文件XML介绍
ResultMap:结果集映射【重点】:
一对多
多对一
log4j
分页
注解开发
动态SQL
缓存【重点】:
一级缓存(本地缓存——默认开启)一次会话有效
二级缓存 (全局缓存)首先请求的是二级,没有二级缓存才会请求一级缓存,还没有就去数据库
缓存失效有四种情况:
1.请求的内容不同
2.进行了新增、修改和删除 操作
3.查询不同的Mapper.xml
4. 手动清理缓存 sqlSession.clearCache();
生命周期和作用域:
生命周期,和作用域,是至关重要的,因为错误的使用会导致非常严重的并发问题。
为什么说Mybatis是半自动ORM映射工具?它与全自动的区别在哪里?
Hibernate属于全自动ORM映射工具,使用Hibernate查询关联对象或者关联集合对象时,可以根据对象关系模型直接获取,所以它是全自动的。而Mybatis在查询关联对象或关联集合对象时,需要手动编写sql来完成,所以,称之为半自动ORM映射工具
什么是 Mybatis?
Mybaits 的优点:
详细回答:
粗略回答:
MyBatis 框架的缺点:
mybatis-config.xml和 mapper.xml
mybatis核心配置文件:
mybatis-config.xml
注意!!!!在 configuration 里面的标签有顺序的限制 排序如下:
properties、settings、typeAliases、typeHandlers、objectFactory、objectWrapperFactory、
reflectorFactory、plugins、environments、databaseIdProvider、mappers
<properties resource="db.properties">
<!--这里面的等同于 db.properties里面的 username=root pwd=123456 优先级1-->
<property name="username" value="root"/>
<property name="pwd" value="123456"/> 优先级1
</properties>
<settings>
<!-- 配置日志格式 (标准日志格式:STDOUT_LOGGING) -->
<setting name="logImpl" value="STDOUT_LOGGING"/>
<!--是否开启自动驼峰命名规则 camel case 映射 -->
<setting name="mapUnderscoreToCamelCase" value="true"/>
<!-- 二级缓存第一步: 显示的开启全局缓存-->
<setting name="cacheEnabled" value="true"/>
</settings>
<typeAliases>
<typeAlias type="com.hh.pojo.User" alias="User"/> <!-- 实体类比较少的时候,使用。 (可以DIY别名)-->
<!-- <package name="com.hh.pojo"/>--> <!--直接扫描整个实体类包,实体类十分多的时候使用,如果想要DIY别名可以在实体上增加注解 @Alias("hello")-->
</typeAliases>
<!--普通注册方式 -->
<typeHandlers>
<typeHandler javaType="String" jdbcType="NVARCHAR" handler="priv.dengjl.ns.handler.MyStringHandler" />
</typeHandlers>
<!--包方式 包方式需要显示在java类注类型:@MappedJdbcTypes(JdbcType.NVARCHAR) @MappedTypes(String.class)-->
<typeHandlers>
<package name="org.mybatis.example"/>
</typeHandlers>
plugins:插件
<plugins>
<plugin interceptor="org.mybatis.example.ExamplePlugin">
<property name="someProperty" value="100"/>
</plugin>
</plugins>
<environments default="development"><!--development:开发环境 -->
<!--environment:环境子属性对象 -->
<environment id="development">
<!--事务管理器:transactionManager -->
<transactionManager type="JDBC"/>
<!-- 数据源:dataSource -->
<dataSource type="POOLED">
<property name="driver" value="${driver}"/>
<property name="url" value="${url}"/>
<property name="username" value="${username}"/>
<property name="password" value="${password}"/> <!-- ${pwd}-->
</dataSource>
</environment>
<environment id="test"><!--test:测试环境 -->
<transactionManager type="JDBC"/>
<dataSource type="POOLED">
<property name="driver" value="com.mysql.jdbc.Driver"/>
<property name="url"
value="jdbc:mysql://localhost:3306/hhmybatis?useSSL=true&useUnicode=true&characterEncoding=UTF-8"/>
<property name="username" value="root"/>
<property name="password" value="123456"/>
</dataSource>
</environment>
</environments>
<databaseIdProvider type="DB_VENDOR">
<property name="SQL Server" value="sqlserver" />
<property name="MySQL" value="mysql" />
<property name="DB2" value="db2" />
<property name="Oracle" value="oracle" />
</databaseIdProvider>
<mappers>
<mapper resource="com/hh/dao/UserMapper.xml"/>
<mapper class="com.hh.dao.BlogMapper"/>
</mappers>
mapper.xml
parameterType:参数数据类型
UserDao
:
public User getById(int id);//基本数据类型 通过id查找User
public User getByName(String name);//string类型 通过name查询User
public User getById2(Integer id);//包装类 通过id查找User
public User getByNameAge(int id,String name);//多个参数 通过name和age查询User
public User getByUser(User user);//POJO 根据Usesr封装对象查询User
UserMapper.xml
:
<mapper>
<select id="getById" parameterType="int" resultType="com.hh.pojo.User">
SELECT * FROM t_user WHERE id=#{id}
</select>
<select id="getByName" parameterType="java.lang.String" resultType="com.hh.pojo.User">
select * from t_user where name = #{name}
</select>
<select id="getById2" parameterType="java.lang.Integer" resultType="com.hh.pojo.User">
select * from t_user where id=#{id}
</select>
<!--两个参数分别是String类型和int类型,类型不一致,所以此时parameterType可以省略,通过参数下标取出参数值-->
<select id="getByNameAge" resultType="com.hh.pojo.User">
select * from t_user where name = #{0} and age = #{1}
</select>
<!--很显然,当有多个参数时,一个一个写太麻烦了,这时候我们可以将参数列表进行封装,将封装对象作为parameterType的值-->
<select id="getByUser" parameterType="com.hh.pojo.User" resultType="com.hh.pojo.User">
select * from t_user where name = #{name} and age = #{age}
</select>
</mapper>
resultType:结果类型
UserDao
:
public int getCount();// 基本数据类型,统计User总数。
public Integer getCount2();// 包装类,统计User总数。
public String getNameById(int id);//String类型,根据id查询User的name值。
UserMapper.xml
:
<mapper>
<select id="getCount" resultType="int">
select count(*) from t_user
</select>
<select id="getCount2" resultType="java.lang.Integer">
select count(*) from t_user
</select>
<select id="getNameById" parameterType="int" resultType="java.lang.String">
select name from user where id = #{name}
</select>
</mapper>
MyBatis 框架适用场合
MyBatis 专注于 SQL 本身,是一个足够灵活的 DAO 层解决方案。对性能的要求很高,或者需求变化较多的项目,如互联网项目,MyBatis 将是不错的选择。
#{}和${}的区别是什么?
#{}是预编译处理,$ {}是字符串替换。
Mybatis 在处理#{}时,会将 sql 中的#{}替换为?号,调用 PreparedStatement(预声明) 的set 方法来赋值;
Mybatis 在处理$ {}时,就是把${}替换成变量的值。使用#{}可以有效的防止 SQL 注入,提高系统安全性。
当实体类中的属性名和表中的字段名不一样 ,怎么办 ?
1.通过在xml里面的sql 查询语句中 定义字段的别名,别名跟实体类的属性名一致
config.xml文件【typeAliases:给实体类起别名,一般默认别名为类名的小写:也就是 user】
<typeAliases>
<typeAlias type="com.hh.pojo.User" alias="User"/>
</typeAliases>
mapper.xml
<mapper>
<select id="getById" parameterType="int" resultType="com.hh.pojo.User">
SELECT * FROM t_user WHERE id=#{id}
</select>
</mapper>
2.通过
来映射字段名和实体类属性名的一一对应的关系
<resultMap id="TeacherStudent" type="Teacher">
<!--
property:实体类字段;column:对应数据库的字段
用id 属性来映射主键字段;用 result 属性来映射非主键字段
复杂的属性,我们需要单独处理 【对象:association ;集合:collection】
javaType="" 指定属性的类型! 集合中的泛型信息,我们使用ofType获取
-->
<id property="id" column="tid"/>
<result property="name" column="tname"/>
<collection property="students" ofType="Student">
<result property="id" column="sid"/>
<result property="name" column="sname"/>
<result property="tid" column="tid"/>
</collection>
</resultMap>
1.在 Java 代码中添加 sql 通配符。
string wildcardname = “%smi%”;
list<name> names = mapper.selectlike(wildcardname);
<select id=”selectlike”>
select * from foo where bar like #{value}
</select>
2.在 sql 语句中拼接通配符,会引起 sql 注入
string wildcardname = “smi”;
list<name> names = mapper.selectlike(wildcardname);
<select id=”selectlike”>
select * from foo where bar like "%"#{value}"%"
</select>
MyBatis动态sql有什么用?执行原理?有哪些动态sql?
Mybatis动态sql可以在Xml映射文件内,以标签的形式编写动态sql,执行原理是根据表达式的值 完成逻辑判断并动态拼接sql的功能。
动态SQL的9个标签:if、choose、when、otherwise、trim、where、set、foreach(collection/open/close/item/sperator/index)、bind
Xml映射文件中,除了常见的select|insert|updae|delete标签之外,还有哪些标签?
,加上动态sql的9个标签,其中为sql片段标签,通过标签引入sql片段,为不支持自增的主键生成策略标签。
通常一个 Xml 映射文件,都会写一个 Dao 接口与之对应,请问,这个 Dao 接口的工作原理是什么?Dao接口里的方法,参数不同时,方法能重载吗?
Dao 接口即 Mapper 接口。比如有些人喜欢写UserDao ,有些人喜欢写UserMapper,不管是怎么写,它对应的XML映射文件一般就是写成UserMapper.xml
接口的全限名,就是映射文件中的 namespace 的值;
接口的方法名,就是映射文件中 Mapper 的 Statement 的 id 值;
接口方法内的参数,就是传递给 sql 的参数。
Mapper 接口是没有实现类的,当调用接口方法时,接口全限名+方法名拼接字符串作为 key 值,可唯一定位一个 MapperStatement。在 Mybatis 中,每一个
标签,都会被解析为一个MapperStatement 对象。
举例:com.mybatis3.mappers.StudentDao.findStudentById
,可以唯一找到 namespace 为 com.mybatis3.mappers.StudentDao
下面 id 为findStudentById
的 MapperStatement
。Mapper 接口里的方法,是不能重载的,因为是使用 全限名+方法名 的保存和寻找策略。Mapper 接口的工作原理是 JDK 动态代理,Mybatis 运行时会使用 JDK动态代理为 Mapper 接口生成代理对象 proxy,代理对象会拦截接口方法,转而执行 MapperStatement 所代表的 sql,然后将 sql 执行结果返回。
不同的 Xml 映射文件,如果配置了 namespace,那么 id 可以重复;如果没有配置 namespace,那么 id 不能重复;
原因就是 namespace+id 是作为 Map
的 key使用的,如果没有 namespace,就剩下 id,那么,id 重复会导致数据互相覆盖。有了 namespace,自然 id 就可以重复,namespace 不同,namespace+id 自然也就不同。
一对一 | 一对多 | |
---|---|---|
联合查询 | 联合查询是几个表联合查询,只查询一次, 通过在resultMap里面配置association节点配置一对一的类就可以完成 | 联合查询是几个表联合查询,只查询一次,通过在resultMap里面的collection节点配置一对多的类就可以完成 |
嵌套查询 | 嵌套查询是先查一个表,根据这个表里面的结果的 外键id,去再另外一个表里面查询数据,也是通过association配置,但另外一个表的查询通过select属性配置 | 嵌套查询是先查一个表,根据这个表里面的 结果的外键id,去再另外一个表里面查询数据,也是通过配置collection,但另外一个表的查询通过select节点配置 |
MyBatis 实现一对一方式及操作
有联合查询和嵌套查询
联合查询是几个表联合查询,只查询一次, 通过在resultMap 里面配置 association 节点配置一对一的类就可以完成;
嵌套查询是先查一个表,根据这个表里面的结果的 外键 id,去再另外一个表里面查询数据,也是通过 association 配置,但另外一个表的查询通过 select 属性配置。
MyBatis 实现一对多方式及操作
有联合查询和嵌套查询。
联合查询是几个表联合查询,只查询一次,通过在resultMap 里面的 collection 节点配置一对多的类就可以完成;
嵌套查询是先查一个表,根据这个表里面的 结果的外键 id,去再另外一个表里面查询数据,也是通过配置 collection,但另外一个表的查询通过 select 节点配置。
一对一、一对多的关联查询 ?
<mapper namespace="com.lcb.mapping.userMapper">
<!--association 一对一关联查询 -->
<select id="getClass" parameterType="int" resultMap="ClassesResultMap">
select * from class c,teacher t where c.teacher_id=t.t_id and c.c_id=#{id}
</select>
<resultMap type="com.lcb.user.Classes" id="ClassesResultMap">
<!-- 实体类的字段名和数据表的字段名映射 -->
<id property="id" column="c_id"/>
<result property="name" column="c_name"/>
<association property="teacher" javaType="com.lcb.user.Teacher">
<id property="id" column="t_id"/>
<result property="name" column="t_name"/>
</association>
</resultMap>
<!--collection 一对多关联查询 -->
<select id="getClass2" parameterType="int" resultMap="ClassesResultMap2">
select * from class c,teacher t,student s where c.teacher_id=t.t_id and c.c_id=s.class_id and c.c_id=#{id}
</select>
<resultMap type="com.lcb.user.Classes" id="ClassesResultMap2">
<id property="id" column="c_id"/>
<result property="name" column="c_name"/>
<association property="teacher" javaType="com.lcb.user.Teacher">
<id property="id" column="t_id"/>
<result property="name" column="t_name"/>
</association>
<collection property="student" ofType="com.lcb.user.Student">
<id property="id" column="s_id"/>
<result property="name" column="s_name"/>
</collection>
</resultMap>
</mapper>
Mybatis之association和collection
Mybatis 使用 RowBounds 对象进行分页,它是针对 ResultSet 结果集执行的内存分页,而非物理分页。可以在 sql 内直接书写带有物理分页的参数来完成物理分页功能,也可以使用分页插件来完成物理分页。
分页插件的基本原理是使用 Mybatis 提供的插件接口,实现自定义插件,在插件的拦截方法内拦截待执行的 sql,然后重写 sql,根据 dialect 方言,添加对应的物理分页语句和物理分页参数。
mybatis有两种分页方式:逻辑分页和物理分页。
区别 | 逻辑分页 | 物理分页 |
---|---|---|
使用 MyBatis 自带的 RowBounds 进行分页,它是一次性查询很多数据,然后在数据中再进行检索。 | 自己手写 SQL 分页或使用分页插件 PageHelper,去数据库查询指定条数的分页数据的形式 | |
一次性查询很多数据,然后再在结果中检索分页的数据。这样做弊端是需要消耗大量的内存、有内存溢出的风险、对数据库压力较大。 | 从数据库查询指定条数的数据,弥补了一次性全部查出的所有数据的种种缺点,比如需要大量的内存,对数据库查询压力较大等问题。 |
RowBounds 表面是在“所有”数据中检索数据,其实并非是一次性查询出所有数据,因为 MyBatis 是对 jdbc 的封装,在 jdbc 驱动中有一个 Fetch Size 的配置,它规定了每次最多从数据库查询多少条数据,假如你要查询更多数据,它会在你执行 next()的时候,去查询更多的数据。
就好比你去自动取款机取 10000 元,但取款机每次最多能取 2500 元,所以你要取 4 次才能把钱取完。只是对于 jdbc 来说,当你调用 next()的时候会自动帮你完成查询工作。这样做的好处可以有效的防止内存溢出。
第一种是使用< resultMap >
标签,逐一定义数据库列名和对象属性名之间的映射关系。
第二种是使用 sql 列的别名功能,将列的别名书写为对象属性名。有了列名与属性名的映射关系后,Mybatis 通过反射创建对象,同时使用反射给对象的属性逐一赋值并返回,那些找不到映射关系的属性,是无法完成赋值的。
首先,创建一个简单的 insert 语句:
<insert id=”insertname”>
insert into names (name) values (#{value})
</insert>
然后在 java 代码中像下面这样执行批处理插入
list < string > names = new arraylist();
names.add(“fred”);
names.add(“barney”);
names.add(“betty”);
names.add(“wilma”);
// 注意这里 executortype.batch
sqlsession sqlsession =sqlsessionfactory.opensession(executortype.batch);
try {
namemapper mapper = sqlsession.getmapper(namemapper.class);
for (string name: names) {
mapper.insertname(name);
}
sqlsession.commit();
} catch (Exception e) {
e.printStackTrace();
sqlSession.rollback();
throw e;
}
finally {
sqlsession.close();
}
insert 方法总是返回一个 int 值 ,这个值代表的是插入的行数。如果采用自增长策略,自动生成的键值在 insert 方法执行完后可以被设置到传入的参数对象中。
示例:
<insert id=”insertname” usegeneratedkeys=”true” keyproperty=”id”>
insert into names (name) values (#{name})
</insert>
name name = new name();
name.setname(“fred”);
int rows = mapper.insertname(name);
// 完成后,id 已经被设置到对象中
system.out.println(“rows inserted = ” + rows);
system.out.println(“generated key value = ” + name.getid());
1.DAO层的函数public UserselectUser(String name,String area);
mapper.xml
:
<!--对应的 xml,#{0}代表接收的是 dao 层中的第一个参数,#{1}代表 dao 层中第二个参数,更多参数一致往后加即可。 -->
<select id="selectUser" resultMap="BaseResultMap">
select * fromuser_user_t where user_name = #{0} and user_area=#{1}
</select>
2.使用 @param 注解:
public interface usermapper {
user selectuser(@param(“username”) string username,@param(“hashedpassword”) string hashedpassword);
}
然后,就可以在 xml 像下面这样使用(推荐封装为一个 map,作为单个参数传递给mapper):
<select id=”selectuser” resulttype=”user”>
select id, username, hashedpassword from some_table
where username = #{username} and hashedpassword = #{hashedpassword}
</select>
3.多个参数封装成 map
try {
//映射文件的命名空间.SQL 片段的 ID,就可以调用对应的映射文件中的SQL
//由于我们的参数超过了两个,而方法中只有一个 Object 参数收集,因此我们使用 Map 集合来装载我们的参数
Map < String, Object > map = new HashMap();
map.put("start", start);
map.put("end", end);
return sqlSession.selectList("StudentID.pagination", map);
} catch (Exception e) {
e.printStackTrace();
sqlSession.rollback();//回滚
throw e;
} finally {
MybatisUtil.closeSqlSession();//关闭sqlsession
}
Mybatis 仅支持 association 关联对象和 collection 关联集合对象的延迟加载,association 指的就是一对一,collection 指的就是一对多查询。在 Mybatis配置文件中,可以配置是否启用延迟加载lazyLoadingEnabled=true/false
。
它的原理是,使用 CGLIB 创建目标对象的代理对象,当调用目标方法时,进入拦截器方法,比如调用 a.getB().getName()
,拦截器 invoke()
方法发现 a.getB()
是null 值,那么就会单独发送事先保存好的查询关联 B 对象的 sql,把 B 查询上来,然后调用 a.setB(b)
,于是 a 的对象 b 属性就有值了,接着完成 a.getB().getName()
方法的调用。这就是延迟加载的基本原理。【是调用的时候触发加载,而不是在初始化的时候就加载信息。】
当然了,不光是 Mybatis,几乎所有的包括 Hibernate,支持延迟加载的原理都是一样的。
Mybatis 的一级、二级缓存以及缓存失效的情况
1)一级缓存
一级缓存也叫本地缓存: SqlSession
与数据库同一次会话期间查询到的数据会放在本地缓存中。
以后如果需要获取相同的数据,直接从缓存中拿,没必须再去查询数据库;
Mybatis对缓存提供支持,但是在没有配置的默认情况下,它只开启一级缓存,一级缓存只是相对于同一个SqlSession而言。所以在参数和SQL完全一样的情况下,我们使用同一个SqlSession对象调用一个Mapper方法,往往只执行一次SQL,因为使用SelSession第一次查询后,MyBatis会将其放在缓存中,以后再查询的时候,如果没有声明需要刷新,并且缓存没有超时的情况下,SqlSession都会取出当前缓存的数据,而不会再次发送SQL到数据库。
为什么要使用一级缓存,不用多说也知道个大概。但是还有几个问题我们要注意一下。
1、一级缓存的生命周期有多长?
a、MyBatis在开启一个数据库会话时,会 创建一个新的SqlSession对象,SqlSession对象中会有一个新的Executor对象。Executor对象中持有一个新的PerpetualCache对象;当会话结束时,SqlSession对象及其内部的Executor对象还有PerpetualCache对象也一并释放掉。
b、如果SqlSession调用了close()方法,会释放掉一级缓存PerpetualCache对象,一级缓存将不可用。
c、如果SqlSession调用了clearCache(),会清空PerpetualCache对象中的数据,但是该对象仍可使用。
d、SqlSession中执行了任何一个update操作(update()、delete()、insert()) ,都会清空PerpetualCache对象的数据,但是该对象可以继续使用
2、怎么判断某两次查询是完全相同的查询?
mybatis认为,对于两次查询,如果以下条件都完全一样,那么就认为它们是完全相同的两次查询。
2.1 传入的statementId
2.2 查询时要求的结果集中的结果范围
2.3. 这次查询所产生的最终要传递给JDBC java.sql.Preparedstatement的Sql语句字符串(boundSql.getSql() )
2.4 传递给java.sql.Statement要设置的参数值
缓存失效的情况:
1.查询不同的东西
2.执行CRUD操作(改变原来的数据所以必定会刷新缓存)
3.查询不同的Mapper.xml
4.手动清理缓存 sqlSession.clearCache();
小结:一级缓存默认是开启的,只在一次SqlSession中有效,也就是拿到连接到关闭连接这个区间段!
一级缓存就是一个Map。
2)二级缓存
二级缓存也叫全局缓存,一级缓存作用域太低了,所以诞生了二级缓存,二级缓存是基于namespace级别的缓存,一个名称空间,对应一个二级缓存;
工作机制
一个会话查询一条数据,这个数据就会被放在当前会话的一级缓存中;
如果当前会话关闭了,这个会话对应的一级缓存就没了;
但是我们想要的是,会话关闭了,一级缓存中的数据被保存到二级缓存中;
新的会话查询信息,就可以从二级缓存中获取内容;
不同的mapper查出的数据会放在自己对应的缓存(mapper)中;
MyBatis的二级缓存是Application级别的缓存,它可以提高对数据库查询的效率,以提高应用的性能。
MyBatis的缓存机制整体设计以及二级缓存的工作模式
SqlSessionFactory层面上的二级缓存默认是不开启的,二级缓存的开席需要进行配置,实现二级缓存的时候,MyBatis要求返回的POJO必须是可序列化的。 也就是要求实现Serializable接口,配置方法很简单,只需要在映射XML文件配置就可以开启缓存了,如果我们配置了二级缓存就意味着:
小结:
只要开启了二级缓存,在同一个Mapper下就有效
所有的数据都会先放在一级缓存中;
只有当会话提交,或者关闭的时候,才会提交到二级缓中!
在一级缓存和二级缓存同时开启时(一级默认开启,二级手动开启),默认先调用二级缓存
缓存更新机制:当某一个作用域(一级缓存 Session/二级缓存 Mapper)进行了C/U/D 操作后,默认该作用域下所有 select 中的缓存将被 clear。
缓存失效的四种情况:
1.查询不同的东西
2.执行CRUD操作(改变原来的数据所以必定会刷新缓存)
3.查询不同的Mapper.xml
4.手动清理缓存 sqlSession.clearCache();
接口绑定,就是在 MyBatis 中任意定义接口,然后把接口里面的方法和 SQL 语句绑定, 我们直接调用接口方法就可以,这样比起原来了 SqlSession 提供的方法我们可以有更加灵活的选择和设置。
接口绑定有两种实现方式
1.通过注解绑定,就是在接口的方法上面加上@Select、@Update 等注解,里面包含 Sql 语句来绑定;
2.通过 xml里面写 SQL 来绑定, 在这种情况下,要指定 xml 映射文件里面的 namespace 必须为接口的全路径名。
当 Sql 语句比较简单时候,用注解绑定, 当 SQL 语句比较复杂时候,用 xml 绑定,一般用 xml 绑定的比较多。
1、Mapper 接口方法名和 mapper.xml 中定义的每个 sql 的 id 相同;
2、Mapper 接口方法的输入参数类型和 mapper.xml 中定义的每个 sql 的parameterType 的类型相同;
3、Mapper 接口方法的输出参数类型和 mapper.xml 中定义的每个 sql 的resultType 的类型相同;
4、Mapper.xml 文件中的 namespace 即是 mapper 接口的类路径。
SqlSessionDaoSupport
:使用此种方法需要编写mapper 接口,mapper 接口实现类、mapper.xml 文件。<mappers>
<mapper resource="mapper.xml 文件的地址" />
<mapper resource="mapper.xml 文件的地址" />
</mappers>
this.getSqlSession()
进行数据增删改查。<bean id=" " class="mapper 接口的实现">
<property name="sqlSessionFactory" ref="sqlSessionFactory"></property>
</bean>
org.mybatis.spring.mapper.MapperFactoryBean
:<mappers>
<mapper resource="mapper.xml 文件的地址" />
<mapper resource="mapper.xml 文件的地址" />
</mappers>
<bean id="" class="org.mybatis.spring.mapper.MapperFactoryBean">
<property name="mapperInterface" value="mapper 接口地址" />
<property name="sqlSessionFactory" ref="sqlSessionFactory" />
</bean>
mapper.xml 文件编写:
mapper.xml 中的 namespace 为 mapper 接口的地址;
mapper 接口中的方法名和 mapper.xml 中的定义的 statement 的 id 保持一致;
如果将 mapper.xml 和 mapper 接口的名称保持一致则不用在 sqlMapConfig.xml中进行配置。
定义 mapper 接口:
注意 mapper.xml 的文件名和 mapper 的接口名称保持一致,且放在同一个目录
配置 mapper 扫描器:
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="mapper 接口包地址"></property>
<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
</bean>
Mybatis 仅可以编写针对 ParameterHandler、ResultSetHandler、StatementHandler、Executor 这 4 种接口的插件,Mybatis 使用 JDK 的动态代理,为需要拦截的接口生成代理对象以实现接口方法拦截功能,每当执行这 4 种接口对象的方法时,就会进入拦截方法,具体就是 InvocationHandler 的 invoke()方法,当然,只会拦截那些你指定需要拦截的方法。
编写插件:实现 Mybatis 的 Interceptor 接口并复写 intercept()方法,然后在给插件编写注解,指定要拦截哪一个接口的哪些方法即可,记住,别忘了在配置文件中配置你编写的插件。
编写一个自定义插件?
自定义插件实现原理*
MyBatis 自定义插件针对 MyBatis 四大对象(Executor、StatementHandler、ParameterHandler、ResultSetHandler)进行拦截:
自定义插件实现关键
MyBatis 插件要实现 Interceptor 接口,接口包含的方法,如下:
public interface Interceptor {
Object intercept(Invocation invocation) throws Throwable;
Object plugin(Object target);
void setProperties(Properties properties);
}
自定义插件实现示例
官方插件实现:
@Intercepts({@Signature(type = Executor. class, method = "query",
args = {MappedStatement. class, Object. class, RowBounds. class, ResultHandler. class})})
public class TestInterceptor implements Interceptor {
public Object intercept(Invocation invocation) throws Throwable {
Object target = invocation. getTarget(); //被代理对象
Method method = invocation. getMethod(); //代理方法
Object[] args = invocation. getArgs(); //方法参数
// do something . . . . . . 方法拦截前执行代码块
Object result = invocation. proceed();
// do something . . . . . . . 方法拦截后执行代码块
return result;
}
public Object plugin(Object target) {
return Plugin. wrap(target, this);
}
}
MyBatis 有三种基本的Executor执行器:
SimpleExecutor:每执行一次 update 或 select 就开启一个 Statement 对象,用完立刻关闭 Statement 对象;
ReuseExecutor:执行 update 或 select,以 SQL 作为 key 查找 Statement 对象,存在就使用,不存在就创建,用完后不关闭 Statement 对象,而是放置于 Map 内供下一次使用。简言之,就是重复使用 Statement 对象;
BatchExecutor:执行 update(没有 select,jdbc 批处理不支持 select),将所有 SQL 都添加到批处理中(addBatch()),等待统一执行(executeBatch()),它缓存了多个 Statement 对象,每个 Statement 对象都是 addBatch()完毕后,等待逐一执行 executeBatch()批处理,与 jdbc 批处理相同。
MyBatis | hibernate | |
---|---|---|
灵活性 | 更加灵活,自己可以写 SQL 语句,使用起来比较方便 | hibernate 是对 jdbc 的封装,简化了数据访问层的繁琐的重复性代码,那样也意味着它对于SQL语句的编写不够灵活 |
可移植性 | 较差(MyBatis 有很多自己写的 SQL,因为每个数据库的 SQL 可以不相同,所以可移植性比较差) | hibernate 是一个优秀的 ORM 实现,很多程度上简化了 DAO 层的编码功能。可以很方便的进行数据库的移植工作 |
学习和使用门槛 | 简单、门槛低 | 较高,需要对持久层的设计模式有一定的经验或理解 |
二级缓存 | 存储在 sqlsessionfactory里 | hibernate 拥有更好的二级缓存,它的二级缓存可以自行更换为第三方的二级缓存 |
什么是ORM(对象关系映射)框架?
ORM是把数据库中的关系数据映射成为程序中的对象
优点:提高开发效率节省开发成本,开发更简单更对象化,可移植性更强
在 Config 里面把 hibernate. show_SQL 设置为 true 就可以。但不建议开启,开启之后会降低程序的运行效率。
有三种:
hibernate.connection.show_sql=true
true
<prop key="hibernate.connection.show_sql">
true
</prop>
log4j.logger.org.hibernate.SQL=DEBUG
log4j.logger.org.hibernate.type=DEBUG
log4j.logger.org.hibernate.tool.hbm2ddl=DEBUG
log4j.logger.org.hibernate.hql=DEBUG
log4j.logger.org.hibernate.cache=DEBUG
log4j.logger.org.hibernate.transaction=DEBUG
log4j.logger.org.hibernate.jdbc=DEBUG
log4j.logger.org.hibernate.connection.DriverManagerConnectionProvider=DEBUG
log4j.logger.org.hibernate.type.descriptor.sql.BasicBinder=DEBUG
hibernate有几种查询方式?
3种:hql、原生SQL、条件查询criteria
实体类可以定义为 final 类,但这样的话就不能使用 hibernate 代理模式下的延迟关联提供性能了,所以不建议定义实体类为 final。
Integer 类型为对象,它的值允许为 null,
int 属于基础数据类型,值不能为 null。
hibernate 常用的缓存有一级缓存和二级缓存:
一级缓存:也叫 Session 缓存,只在 Session 作用范围内有效,不需要用户干涉,由 hibernate 自身维护,可以通过:evict(object)清除 object 的缓存;clear()清除一级缓存中的所有缓存;flush()刷出缓存;
二级缓存:应用级别的缓存,在所有 Session 中都有效,支持配置第三方的缓存,如:EhCache。
《EhCache缓存原理及配置》
《Ehcache缓存设计原理》
hibernate 对象有哪些状态?
临时/瞬时状态:直接 new 出来的对象,该对象还没被持久化(没保存在数据库中),不受 Session 管理。
持久化状态:当调用 Session 的 save/saveOrupdate/get/load/list 等方法的时候,对象就是持久化状态。
游离状态:Session 关闭之后对象就是游离状态。
getCurrentSession 会绑定当前线程,而 openSession 则不会。
getCurrentSession 事务是 Spring 控制的,并且不需要手动关闭,而 openSession 需要我们自己手动开启和提交事务。
hibernate 中每个实体类必须提供一个无参构造函数,因为 hibernate 框架要使用 reflection api
,通过调用 ClassnewInstance()
来创建实体类的实例,如果没有无参的构造函数就会抛出异常。
Kafka 和 Zookeeper
ZooKeeper 是一个开放源码的分布式协调服务,它是集群的管理者,监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终,将简单易用的接口和性能高效、功能稳定的系统提供给用户。分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Zookeeper 保证了如下分布式一致性特性:顺序一致性、原子性、单一视图、可靠性、实时性(最终一致性)
客户端的读请求可以被集群中的任意一台机器处理,如果读请求在节点上注册了监听器,这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求,这些请求会同时发给其他 zookeeper 机器并且达成一致后,请求才会返回成功。因此, 随着 zookeeper 的集群机器增多,读请求的吞吐会提高但是写请求的吞吐会下降。有序性是 zookeeper 中非常重要的一个特性,所有的更新都是全局有序的,每个更新都有一个唯一的时间戳,这个时间戳称为 zxid(Zookeeper Transaction Id)。而读请求只会相对于更新有序,也就是读请求的返回结果中会带有这个zookeeper 最新的 zxid。
ZooKeeper 提供了什么?
1、文件系统
2、通知机制
zookeeper 文件系统
Zookeeper 提供一个多层级的节点命名空间(节点称为 znode)。与文件系统不同的是,这些节点都可以设置关联的数据,而文件系统中只有文件节点可以存放数据而目录节点不行。
Zookeeper 为了保证高吞吐和低延迟,在内存中维护了这个树状的目录结构,这种特性使得 Zookeeper 不能用于存放大量的数据,每个节点的存放数据上限为1M。
zookeeper 都有哪些功能?
zookeeper 有几种部署模式?
zookeeper 有三种部署模式:
zookeeper 怎么保证主从节点的状态同步?
zookeeper 的核心是原子广播,这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 zab 协议。 zab 协议有两种模式,分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,zab 就进入了恢复模式,当领导者被选举出来,且大多数 server 完成了和 leader 的状态同步以后,恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。
集群中为什么要有主节点?
在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,所以就需要主节点。
集群中有 3 台服务器,其中一个节点宕机,这个时候 zookeeper 还可以使用吗?
可以继续使用,单数服务器只要没超过一半的服务器宕机就可以继续使用。
说一下 zookeeper 的通知机制?
客户端端会对某个 znode(数据节点) 建立一个 watcher (监察)事件,当该 znode 发生变化时,这些客户端会收到 zookeeper 的通知,然后客户端可以根据 znode 变化来做出业务上的改变。
服务器角色
Leader
1、事务请求的唯一调度和处理者,保证集群事务处理的顺序性
2、集群内部各服务的调度者
Follower
1、处理客户端的非事务请求,转发事务请求给 Leader 服务器
2、参与事务请求 Proposal 的投票
3、参与 Leader 选举投票
Observer
1、3.0 版本以后引入的一个服务器角色,在不影响集群事务处理能力的基础上提
升集群的非事务处理能力
2、处理客户端的非事务请求,转发事务请求给 Leader 服务器
3、不参与任何形式的投票
ZAB 协议?
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。
ZAB 协议包括两种基本的模式:崩溃恢复和消息广播。
当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时,所有进程(服务器)进入崩溃恢复模式,首先选举产生新的 Leader 服务器,然后集群中 Follower(追随者或者说子服务) 服务器开始
与新的 Leader 服务器进行数据同步,当集群中超过半数机器与该 Leader服务器完成数据同步之后,退出恢复模式进入消息广播模式,
Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
简单比喻总结:zookeeper是以树状结构存在的,在服务过程中如果leader(领导者/父节点)挂掉了,那么整个服务就会进入瘫痪的状态,然后会从其他的follower(追随者/子节点)选举新的leader,同步数据后又可以继续使用了
Zookeeper 下 Server 工作状态
服务器具有四种状态,分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
1、LOOKING:寻找 Leader 状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader 选举状态。
2、FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。
3、LEADING:领导者状态。表明当前服务器角色是 Leader。
4、OBSERVING:观察者状态。表明当前服务器角色是 Observer。
数据同步
整个集群完成 Leader 选举之后,Learner(Follower 和 Observer 的统称)会向Leader 服务器进行注册。当 Learner 服务器想 Leader 服务器完成注册后,进入数据同步环节。
数据同步流程:(均以消息传递的方式进行)Learner 向 Learder 注册——数据同步——同步确认
Zookeeper 的数据同步通常分为四类:
1、直接差异化同步(DIFF 同步)
2、先回滚再差异化同步(TRUNC+DIFF 同步)
3、仅回滚同步(TRUNC 同步)
4、全量同步(SNAP 同步)
在进行数据同步前,Leader 服务器会完成数据同步初始化:
peerLastZxid:
- 从 learner 服务器注册时发送的 ACKEPOCH 消息中提取 lastZxid(该Learner 服务器最后处理的 ZXID)
minCommittedLog:
- Leader 服务器 Proposal 缓存队列 committedLog 中最小 ZXID
maxCommittedLog:
- Leader 服务器 Proposal 缓存队列 committedLog 中最大 ZXID
直接差异化同步(DIFF 同步)
- 场景:peerLastZxid 介于 minCommittedLog 和 maxCommittedLog之间先回滚再差异化
同步(TRUNC+DIFF 同步)
- 场景:当新的 Leader 服务器发现某个 Learner 服务器包含了一条自己没有的事务记录,那么就需要让该 Learner 服务器进行事务回滚--回滚到 Leader 服务器上存在的,同时也是最接近于 peerLastZxid 的 ZXID
仅回滚同步(TRUNC 同步)
- 场景:peerLastZxid 大于 maxCommittedLog
全量同步(SNAP 同步)
- 场景一:peerLastZxid 小于 minCommittedLog
- 场景二:Leader 服务器上没有 Proposal 缓存队列且 peerLastZxid 不等于 lastProcessZxid
zookeeper 是如何保证事务的顺序一致性的?
zookeeper 采用了全局递增的事务 Id 来标识,所有的 proposal(提议)都在被提出的时候加上了 zxid,zxid 实际上是一个 64 位的数字,高 32 位是 epoch用来标识 leader 周期,如果有新的 leader 产生出来,epoch会自增,低 32 位用来递增计数。当新产生 proposal 的时候,会依据数据库的两阶段过程,首先会向其他的 server 发出事务执行请求,如果超过半数的机器都能执行并且能够成功,那么就会开始执行。
四种类型的数据节点 Znode
PERSISTENT-持久节点:除非手动删除,否则节点一直存在于 Zookeeper 上
EPHEMERAL-临时节点:临时节点的生命周期与客户端会话绑定,一旦客户端会话失效(客户端与zookeeper 连接断开不一定会话失效),那么这个客户端创建的所有临时节点都会被移除。
PERSISTENT_SEQUENTIAL-持久顺序节点:基本特性同持久节点,只是增加了顺序属性,节点名后边会追加一个由父节点维护的自增整型数字。
EPHEMERAL_SEQUENTIAL-临时顺序节点:基本特性同临时节点,增加了顺序属性,节点名后边会追加一个由父节点维护的自增整型数字。
Zookeeper Watcher 机制 – 数据变更通知
Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听,当服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。
工作机制:
Watcher 特性总结:
一次性
无论是服务端还是客户端,一旦一个 Watcher 被触发,Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力,不然对于更新非常频繁的节点,服务端会不断的向客户端发送事件通知,无论对于网络还是服务端的压力都非常大。
客户端串行执行
客户端 Watcher 回调的过程是一个串行同步的过程。
轻量
3.1. Watcher 通知非常简单,只会告诉客户端发生了事件,而不会说明事件的具体内容。
3.2. 客户端向服务端注册 Watcher 的时候,并不会把客户端真实的 Watcher 对象实体传递到服务端,仅仅是在客户端请求中使用 boolean 类型属性进行了标记。
watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步的,这就存在一个问题,不同的客户端和服务器之间通过 socket 进行通信,由于网络延迟或其他因素导致客户端在不通的时刻监听到事件,由于 Zookeeper 本身提供了 ordering guarantee,即客户端监听事件后,才会感知它所监视 znode发生了变化。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化。Zookeeper 只能保证最终的一致性,而无法保证强一致性。
注册 watcher getData、exists、getChildren
触发 watcher create、delete、setData
当一个客户端连接到一个新的服务器上时,watch 将会被以任意会话事件触发。当与一个服务器失去连接的时候,是无法接收到 watch 的。而当 client 重新连接时,如果需要的话,所有先前注册过的 watch,都会被重新注册。通常这是完全透明的。只有在一个特殊情况下,watch 可能会丢失:对于一个未创建的 znode 的 exist watch,如果在客户端断开连接期间被创建了,并且随后在客户端连接上之前又删除了,这种情况下,这个 watch 事件可能会被丢失。
客户端注册 Watcher 实现
服务端处理 Watcher 实现
服务端接收 Watcher 并存储
接收到客户端请求,处理请求判断是否需要注册 Watcher,需要的话将数据节点的节点路径和 ServerCnxn(ServerCnxn 代表一个客户端和服务端的连接,实现了 Watcher 的 process 接口,此时可以看成一个 Watcher 对象)存储在WatcherManager 的 WatchTable 和 watch2Paths 中去。
Watcher 触发
以服务端接收到 setData() 事务请求触发 NodeDataChanged 事件为例:
2.1 封装 WatchedEvent:将通知状态(SyncConnected)、事件类型(NodeDataChanged)以及节点路径封装成一个 WatchedEvent 对象
2.2 查询 Watcher:从 WatchTable 中根据节点路径查找 Watcher
2.3 没找到;说明没有客户端在该数据节点上注册过 Watcher
2.4 找到;提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher(从这里可以看出 Watcher 在服务端是一次性的,触发一次就失效了)
调用 process 方法来触发 Watcher
这里 process 主要就是通过 ServerCnxn 对应的 TCP 连接发送 Watcher 事件通知。
客户端回调
客户端 SendThread 线程接收事件通知,交由 EventThread 线程回调 Watcher。
客户端的 Watcher 机制同样是一次性的,一旦被触发后,该 Watcher 就失效了。
ACL 权限控制机制
UGO(User/Group/Others):目前在 Linux/Unix 文件系统中使用,也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。
ACL(Access Control List)访问控制列表:
包括三个方面:
权限模式(Scheme)
1、IP:从 IP 地址粒度进行权限控制
2、Digest:最常用,用类似于 username:password 的权限标识来进行权限配
置,便于区分不同应用来进行权限控制
3、World:最开放的权限控制方式,是一种特殊的 digest 模式,只有一个权限标
识“world:anyone”
4、Super:超级用户
授权对象
授权对象指的是权限赋予的用户或一个指定实体,例如 IP 地址或是机器灯。
权限 Permission
1、CREATE:数据节点创建权限,允许授权对象在该 Znode 下创建子节点
2、DELETE:子节点删除权限,允许授权对象删除该数据节点的子节点
3、READ:数据节点的读取权限,允许授权对象访问该数据节点并读取其数据内
容或子节点列表等
4、WRITE:数据节点更新权限,允许授权对象对该数据节点进行更新操作
5、ADMIN:数据节点管理权限,允许授权对象对该数据节点进行 ACL 相关设置操作
分布式集群中为什么会有 Master?
在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,于是就需要进行leader 选举。
zk 节点宕机如何处理?
Zookeeper 本身也是集群,推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时,其他节点会继续提供服务。
如果是一个 Follower 宕机,还有 2 台服务器提供访问,因为 Zookeeper 上的数据是有多个副本的,数据并不会丢失;如果是一个 Leader 宕机,Zookeeper 会选举出新的 Leader。ZK 集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在 ZK节点挂得太多,只剩一半或不到一半节点能工作,集群才失效。所以
3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)
2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)
zookeeper 负载均衡和 nginx 负载均衡区别
zk 的负载均衡是可以调控,nginx 只是能调权重,其他需要可控的都需要自己写插件;但是 nginx 的吞吐量比 zk 大很多,应该说按业务选择用哪种方式。
Zookeeper 有哪几种几种部署模式?
部署模式:单机模式、伪集群模式、集群模式。
集群最少要几台机器,集群规则是怎样的?
集群规则为 2N+1 台,N>0,即 3 台。
集群支持动态添加机器吗?
其实就是水平扩容了,Zookeeper 在这方面不太好。
两种方式:
全部重启:关闭所有 Zookeeper 服务,修改配置之后启动。不影响之前客户端的会话。
逐个重启:在过半存活即可用的原则下,一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。
3.5 版本开始支持动态扩容。
Zookeeper 的 java 客户端都有哪些?
java 客户端:zk 自带的 zkclient 及 Apache 开源的 Curator。
zookeeper常用的命令
Is get set create delete……
Zookeeper 对节点的 watch监听通知是永久的吗?为什么不是永久的?
不是。官方声明:一个 Watch 事件是一个一次性的触发器,当被设置了 Watch的数据发生了改变的时候,则服务器将这个改变发送给设置了 Watch 的客户端,以便通知它们。
为什么不是永久的,举个例子,如果服务端变动频繁,而监听的客户端很多情况下,每次变动都要通知到所有的客户端,给网络和服务器造成很大压力。一般是客户端执行 getData(“/节点 A”,true),如果节点 A 发生了变更或删除,客户端会得到它的 watch 事件,但是在之后节点 A 又发生了变更,而客户端又没有设置 watch 事件,就不再给客户端发送。在实际应用中,很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可。
基于 Zookeeper 的实现方式
负载均衡
命名服务是指通过指定的名字来获取资源或者服务的地址,利用 zk 创建一个全局的路径,这个路径就可以作为一个名字,指向集群中的集群,提供的服务的地址,或者一个远程的对象等等。
对于系统调度来说:操作人员发送通知实际是通过控制台改变某个节点的状态,然后 zk 将这些变化发送给注册了这个节点的 watcher 的所有客户端。对于执行情况汇报:每个工作进程都在某个目录下创建一个临时节点。并携带工作的进度数据,这样汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况。
命名服务是指通过指定的名字来获取资源或者服务的地址,利用 zk 创建一个全局的路径,即是唯一的路径,这个路径就可以作为一个名字,指向集群中的集群,提供的服务的地址,或者一个远程的对象等等。
程序分布式的部署在不同的机器上,将程序的配置信息放在 zk 的 znode 下,当有配置发生改变时,也就是 znode 发生变化时,可以通过改变 zk 中某个目录节点的内容,利用 watcher 通知给各个客户端,从而更改配置。
所谓集群管理无在乎两点:是否有机器退出和加入、选举 master。
对于第一点,所有机器约定在父目录下创建临时目录节点,然后监听父目录节点的子节点变化消息。一旦有机器挂掉,该机器与 zookeeper 的连接断开,其所创建的临时目录节点被删除,所有其他机器都收到通知:某个兄弟目录被删除,于是,所有人都知道:它上船了。新机器加入也是类似,所有机器收到通知:新兄弟目录加入,highcount 又有了,对于第二点,我们稍微改变一下,所有机器创建临时顺序编号目录节点,每次选取编号最小的机器作为 master 就好。
有了 zookeeper 的一致性文件系统,锁的问题变得容易。锁服务可以分为两类,一个是保持独占,另一个是控制时序。
对于第一类,我们将 zookeeper 上的一个 znode 看作是一把锁,通过 createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点,最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放
出锁。
对于第二类, /distribute_lock 已经预先存在,所有客户端在它下面创建临时顺序编号目录节点,和选 master 一样,编号最小的获得锁,用完删除,依次方便。
两种类型的队列:
1、同步队列,当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类,在约定目录下创建临时目录节点,监听节点数目是否是我们要求的数目。
第二类,和分布式锁服务中的控制时序场景基本原理一致,入列有编号,出列按编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL 节点,
创建成功时Watcher 通知等待的队列,队列删除序列号最小的节点用以消费。此场景下Zookeeper 的 znode 用于消息存储,
znode 存储的数据就是消息队列中的消息内容,SEQUENTIAL 序列号就是消息的编号,按序取出即可。由于创建的节点是持久化的,
所以不必担心队列消息的丢失问题。
CAP 原则和ACID原则
CAP是什么?(NoSQL (Redis\MongoDB) ===> CAP)
CAP的三进二:
CA、
AP(Eureka --- 例如:阿里、京东)、
CP(Zookeeper --- )
CAP理论的核心
ACID是什么?(RDBMS (MySQL\Oracle\sqlServer) ===> ACID)
原博主:zookeeper和dubbo最本质的区别
Dubbo建议使用Zookeeper作为服务的注册中心。
https://www.cnblogs.com/xiaofei1208/p/7077733.html
Zookeeper的作用:
zookeeper用来注册服务和进行负载均衡,哪一个服务由哪一个机器来提供必需让调用者知道,简单来说就是ip地址和服务名称的对应关系。当然也可以 通过硬编码的方式把这种对应关系在调用方业务代码中实现,但是如果提供服务的机器挂掉调用者无法知晓,如果不更改代码会继续请求挂掉的机器提供服务。 zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发,简单来说就是横向扩展,在不更改代码 的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务,服务的提供者多了能服务的客户就多了。
dubbo:
是管理中间层的工具,在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度,dubbo提供一个框架解决这个问题。
注意这里的dubbo只是一个框架,至于你架子上放什么是完全取决于你的,就像一个汽车骨架,你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心,储存所有服务的元数据,你可以用zk,也可以用别的,只是大家都用zk。
zookeeper和dubbo的关系:
Dubbo的将注册中心进行抽象,是得它可以外接不同的存储媒介给注册中心提供服务,有ZooKeeper,Memcached,Redis等。
引入了ZooKeeper作为存储媒介,也就把ZooKeeper的特性引进来。首先是负载均衡,单注册中心的承载能力是有限的,在流量达到一定程度的时 候就需要分流,负载均衡就是为了分流而存在的,一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡;资源同步,单单有负载均衡还不 够,节点之间的数据和资源需要同步,ZooKeeper集群就天然具备有这样的功能;命名服务,将树状结构用于维护全局的服务地址列表,服务提供者在启动 的时候,向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址,这个操作就完成了服务的发布。 其他特性还有Mast选举,分布式锁等。
两者区别图解:
Zookeeper:保证的是CP(一致性和容错性)。zookeeper是树形结构,结点不是平等的,有leader,一旦出现网络故障,在重选leader的过程整个服务都将瘫痪,这就导致了zookeeper的可用性变低了。
Eureka:保证的是AP(可用性和容错性)。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保住注册服务的可用性,只不过查到的信息可能不是最新的,除此之外,Eureka还有之中自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪
nacos与eureka的区别
Spring-Cloud Eureka是Spring Cloud集合中一个组件,它是对Eureka的集成,用于服务注册和发现。Eureka是Netflix中的一个开源框架
eureka 注册中心:
Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。nacos是阿里团队提供的开源组件
nacos
1、nacos与eureka的共同点
都支持服务注册和服务拉取
都支持服务提供者心跳的方式做健康检测
2、nacos与eureka的区别
nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式(一般情况下都使用临时实例,主动检测消费的服务器资源较大,服务器压力大)
临时实例心跳不正常会被剔除,非临时实例则不会被剔除
nacos支持服务列表变更的消息推送模式,服务列表更新及时
nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;eureka采用AP方式
Kafka
如何获取topic主题的列表: bin/kafka-topics.sh --list --zookeeper localhost:2181
生产者和消费者的命令行是什么?
生产者在主题上发布消息:
bin/kafka-console-producer.sh --broker-list 192.168.43.49:9092 --topic
Hello-Kafka
注意这里的 IP 是 server.properties
中的 listeners 的配置。接下来每个新行就是输入一条新消息。
消费者接受消息:
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic
Hello-Kafka --from-beginning
consumer 是推还是拉?
Kafka 最初考虑的问题是 pull 和 push的问题。在这方面,Kafka 遵循了一种大部分消息系统共同的传统的设计:producer 将消息推送到 broker,consumer 从broker 拉取消息。
一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式,将消息推送到下游的 consumer。这样做有好处也有坏处:由 broker 决定消息推送的速率,对于不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息,但不幸的是,push 模式下,当 broker 推送的速率远大于 consumer 消费的速率时,consumer 恐怕就要崩溃了。最终 Kafka 还是选取了传统的 pull 模式。
Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据。Push 模式必须在不知道下游 consumer 消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免 consumer 崩溃而采用较低的推送速率,将可能导致一次只推送较少的消息而造成浪费。Pull 模式下,consumer 就可以根据自己的消费能力去决定这些策略。
Pull 有个缺点是,如果 broker 没有可供消费的消息,将导致 consumer 不断在循环中轮询,直到新消息到 t 达。为了避免这点,Kafka 有个参数可以让 consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
讲讲 kafka 维护消费状态跟踪的方法
大部分消息系统在 broker 端的维护消息被消费的记录:一个消息被分发到consumer 后 broker 就马上进行标记或者等待 customer 的通知后进行标记。这样也可以在消息在消费后立马就删除以减少空间占用。
但是这样会不会有什么问题呢?
如果一条消息发送出去之后就立即被标记为消费过的,一旦 consumer 处理消息时失败了(比如程序崩溃)消息就丢失了。
为了解决这个问题,很多消息系统提供了另外一个个功能:当消息被发送出去之后仅仅被标记为已发送状态,当接到 consumer 已经消费成功的通知后才标记为已被消费的状态。
这虽然解决了消息丢失的问题,但产生了新问题,
Kafka 采用了不同的策略。Topic 被分成了若干分区,每个分区在同一时间只被一个 consumer 消费。这意味着每个分区被消费的消息在日志中的位置仅仅是一个简单的整数:offset。这样就很容易标记每个分区消费状态就很容易了,仅仅需要一个整数而已。这样消费状态的跟踪就很简单了。
这带来了另外一个好处:consumer 可以把 offset 调成一个较老的值,去重新消费老的消息。这对传统的消息系统来说看起来有些不可思议,但确实是非常有用的,谁规定了一条消息只能被消费一次呢?
参考该文章——《漫游Kafka设计篇之主从同步》
为什么需要消息系统,mysql 不能满足需求吗?
Zookeeper 对于 Kafka 的作用是什么?
Zookeeper 是一个开放源码的、高性能的协调服务,它用于 Kafka 的分布式应用。
Zookeeper 主要用于在集群中不同节点之间进行通信
在 Kafka 中,它被用于提交偏移量,因此如果节点在任何情况下都失败了,它都可以从之前提交的偏移量中获取
除此之外,它还执行其他活动,如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
数据传输的事务定义有哪三种?
和 MQTT 的事务定义一样都是 3 种。
(1)最多一次: 消息不会被重复发送,最多被传输一次,但也有可能一次不传输
(2)最少一次: 消息不会被漏发送,最少被传输一次,但也有可能被重复传输.
(3)精确的一次(Exactly once): 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次,这是大家所期望的
(1)节点必须可以维护和 ZooKeeper 的连接,Zookeeper 通过心跳机制检查每个节点的连接
(2)如果节点是个 follower,他必须能及时的同步 leader 的写操作,延时不能太
(1).Kafka 持久化日志,这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统:它以集群的方式运行,可以灵活伸缩,在内部通过复制数据提升容错能力和高可用性
(3).Kafka 支持实时的流式处理
request.required.acks 有三个值 0 1 -1(all)
0:生产者不会等待 broker 的 ack,这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。
1:服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
-1(all):服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack,这样数据不会丢失
消费者如何不自动提交偏移量,由应用提交?
将 auto.commit.offset
设为 false,然后在处理一批消息后commitSync() 或者异步提交 commitAsync()
即:
ConsumerRecords<> records = consumer.poll();
for (ConsumerRecord<> record : records){
...
tyr{
consumer.commitSync()
}
...
}
出现“活锁”的情况,是它持续的发送心跳,但是没有处理。为了预防消费者在这种情况下一直持有分区,我们使用 max.poll.interval.ms 活跃检测机制。 在此基础上,如果你调用的 poll 的频率大于最大间隔,则客户端将主动地离开组,以便其他消费者接管该分区。 发生这种情况时,你会看到 offset 提交失败(调用commitSync()引发的 CommitFailedException)。这是一种安全机制,保障只有活动成员能够提交 offset。所以要留在组中,你必须持续调用 poll。
消费者提供两个配置设置来控制 poll 循环:
max.poll.interval.ms:增大 poll 的间隔,可以为消费者提供更多的时间去处理返
回的消息(调用 poll(long)返回的消息,通常返回的消息都是一批)。缺点是此值越大将会延迟组重新平衡。
max.poll.records
:此设置限制每次调用 poll 返回的消息数,这样可以更容易的预测每次 poll 间隔要处理的最大值。通过调整此值,可以减少 poll 间隔,减少重新平衡分组的
对于消息处理时间不可预测地的情况,这些选项是不够的。 处理这种情况的推荐方法是将消息处理移到另一个线程中,让消费者继续调用 poll。 但是必须注意确保已提交的 offset 不超过实际位置。另外,你必须禁用自动提交,并只有在线程完成处理后才为记录手动提交偏移量(取决于你)。 还要注意,你需要 pause 暂停分区,不会从 poll 接收到新消息,让线程处理完之前返回的消息(如果你的处理能力比拉取消息的慢,那创建新线程将导致你机器内存溢出)。
kafka 使用 seek(TopicPartition, long)
指定新的消费位置。用于查找服务器保留的最早和最新的 offset 的特殊的方法也可用(seekToBeginning(Collection)
和seekToEnd(Collection))
Kafka 分布式的单位是 partition,同一个 partition 用一个 write ahead log 组织,所以可以保证 FIFO 的顺序。不同 partition 之间不能保证顺序。但是绝大多数用户都可以通过 message key 来定义,因为同一个 key 的 message 可以保证只发送到同一个 partition。
Kafka 中发送 1 条消息的时候,可以指定(topic, partition, key) 3 个参数。partiton 和 key 是可选的。如果你指定了 partition,那就是所有消息发往同 1 个 partition,就是有序的。并且在消费端,Kafka 保证,1 个 partition 只能被 1 个 consumer 消费。或者你指定 key(比如 order id),具有同 1 个 key 的所有消息,会发往同 1 个 partition。
这个问题比较系统,回答出 kafka 的系统特点,leader 和 follower 的关系,消息读写的顺序即可。
Kafka学习之路 (三)Kafka的高可用
图解kafka的高可用机制
https://yq.aliyun.com/articles/64703
Kafka无消息丢失配置
其实还是得结合业务来思考,我这里给几个思路:
比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了,update 一下好吧。比如你是写 Redis,那没问题了,反正每次都是 set,天然幂等性。比如你不是上面两个场景,那做的稍微复杂一点,你需要让生产者发送每条数据的时候,里面加一个全局唯一的 id,类似订单 id 之类的东西,然后你这里消费到了之后,先根据这个 id 去比如 Redis 里查一下,之前消费过吗?如果没有消费过,你就处理,然后这个 id 写 Redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了,重复数据插入只会报错,不会导致数据库中出现脏数据。
kafka 不能脱离 zookeeper 单独使用,因为 kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。
kafka 有两种数据保存策略:按照过期时间保留和按照存储的消息大小保留。
进行清除操作,二者符合其一都会执行清除操作
比如:ES 集群架构 13 个节点,索引根据通道不同共 20+索引,根据日期,每日递增 20+,索引:10 分片,每日递增 1 亿+数据,
每个通道每天索引大小控制:150GB 之内。
仅索引层面调优手段:
1.1、设计阶段调优
1. 根据业务增量需求,采取基于日期模板创建索引,通过 roll over API 滚动索引;
2. 使用别名进行索引管理;
3. 每天凌晨定时对索引做 force_merge 操作,以释放空间;
4. 采取冷热分离机制,热数据存储到 SSD,提高检索效率;冷数据定期进行 shrink操作,以缩减存储;
5. 采取 curator 进行索引的生命周期管理;
6. 仅针对需要分词的字段,合理的设置分词器;
7. Mapping 阶段充分结合各个字段的属性,是否需要检索、是否需要存储等。……..
1.2、写入调优
1. 写入前副本数设置为 0;
2. 写入前关闭 refresh_interval 设置为-1,禁用刷新机制;
3. 写入过程中:采取 bulk 批量写入;
4. 写入后恢复副本数和刷新间隔;
5. 尽量使用自动生成的 id。
1.3、查询调优
1、禁用 wildcard;
2、禁用批量 terms(成百上千的场景);
3、充分利用倒排索引机制,能 keyword 类型尽量 keyword;
4、数据量大时候,可以先基于时间敲定索引再检索;
5、设置合理的路由机制。
1.4、其他调优
部署调优,业务调优等。
上面的提及一部分,面试者就基本对你之前的实践或者运维经验有所评估了。
前置前提:
1、只有候选主节点(master:true)的节点才能成为主节点。
2、最小主节点数(min_master_nodes)的目的是防止脑裂
核心入口为 findMaster,选择主节点成功返回对应 Master,否则返回 null。选举流程大致描述如下:
第一步:确认候选主节点数达标,elasticsearch.yml 设置的值discovery.zen.minimum_master_nodes;
第二步:比较:先判定是否具备 master 资格,具备候选主节点资格的优先返回;若两节点都为候选主节点,则 id 小的值会主节点。注意这里的 id 为 string 类型。题外话:获取节点 id 的方法。
1 GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name
2 ip port heapPercent heapMax id name
discovery.zen.minimum_master_nodes
)超过所有候选节点一半以上来解决脑裂问题;推荐:详细描述一下 Elasticsearch 搜索的过程
Redis 是完全开源免费的,遵守 BSD 协议,是一个高性能的 key-value 数库。(Redis 是一个使用 C 语言开发的高速缓存数据库。)
Redis 与其他 key - value 缓存产品有以下三个特点:
1. Redis 支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
2. Redis 不仅仅支持简单的 key-value 类型的数据,同时还提供 list,set,zset,hash 等数据结构的存储。
3. Redis 支持数据的备份,即 master-slave 模式的数据备份。
Redis 优势
Strings, Lists, Hashes, Sets 及Ordered Sets
数据类型操作。Redis 与其他 key-value 存储有什么不同?
Redis 有着更为复杂的数据结构并且提供对他们的原子性操作,这是一个不同于其他数据库的进化路径。Redis 的数据类型都是基于基本数据结构的同时对程序员透明,无需进行额外的抽象。
Redis 运行在内存中但是可以持久化到磁盘,所以在对不同数据集进行高速读写时,需要权衡内存,因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是,相比在磁盘上相同的复杂的数据结构,在内存中操作起来非常简单,这样 Redis可以做很多内部复杂性很强的事情。同时,在磁盘格式方面他们是紧凑的以追加的方式产生的,因为他们并不需要进行随机访问。
Redis 最适合的场景?
简答:Redis 使用场景:
记录帖子点赞数、点击数、评论数;
缓存近期热帖;
缓存文章详情信息;
记录用户会话信息。
详细解答:
1、会话缓存(Session Cache)
最常用的一种使用 Redis 的情景是会话缓存(session cache)。用 Redis 缓存会话比其他存储(如 Memcached)的优势在于:
Redis 提供持久化。当维护一个不是严格要求一致性的缓存时,如果用户的购物车信息全部丢失,大部分人都会不高兴的,
现在,他们还会这样吗? 幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用 Redis 来缓存会话的文档。
甚至广为人知的商业平台Magento 也提供 Redis 的插件。
2、全页缓存(FPC)
除基本的会话 token 之外,Redis 还提供很简便的 FPC 平台。回到一致性问题,即使重启了 Redis 实例,因为有磁盘的持久化,
用户也不会看到页面加载速度的下降,这是一个极大改进,类似 PHP 本地 FPC。 再次以 Magento 为例,
Magento提供一个插件来使用 Redis 作为全页缓存后端。 此外,对 WordPress 的用户来说,Pantheon 有一个非常好的插件 wp-redis,
这个插件能帮助你以最快速度加载你曾浏览过的页面。
3、队列
Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作,这使得 Redis
能作为一个很好的消息队列平台来使用。Redis 作为队列使用的操作,就类似于本地程序语言(如 Python)对 list 的 push/pop 操作。
如果你快速的在 Google 中搜索“Redis queues”,你马上就能找到大量的开源项目,这些项目的目的就
是利用 Redis 创建非常好的后端工具,以满足各种队列需求。例如,Celery 有一个后台就是使用 Redis 作为 broker,你可以从这里去查看。
4,排行榜/计数器
Redis 在内存中对数字进行递增或递减的操作实现的非常好。集合(Set)和有序集合(Sorted Set)也使得我们在执行这些操作的时候变的非常简单,
Redis 只是正好提供了这两种数据结构。所以,我们要从排序集合中获取到排名最靠前的 10个用户–我们称之为“user_scores”,
我们只需要像下面一样执行即可: 当然,这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数,
你需要这样执行: ZRANGE user_scores 0 10 WITHSCORES Agora Games 就是一个很好的例子,用 Ruby 实现的,
它的排行榜就是使用 Redis 来存储数据的,你可以在这里看到。
5、发布/订阅
最后(但肯定不是最不重要的)是 Redis 的发布/订阅功能。发布/订阅的使用场景确实非常多。
我已看见人们在社交网络连接中使用,还可作为基于发布/订阅的脚本触发器,甚至用 Redis 的发布/订阅功能来建立聊天系统!
Redis 有哪些功能?
Redis 数据类型有哪些?
Redis 为什么是单线程的?
因为 cpu 不是 Redis 的瓶颈,Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现,而且 cpu 又不会成为瓶颈,那就顺理成章地采用单线程的方案了。
关于 Redis 的性能,官方网站也有,普通笔记本轻松处理每秒几十万的请求。
而且单线程并不代表就慢 nginx 和 nodejs 也都是高性能单线程的代表。
【Redis 是单进程单线程的,redis 利用队列技术将并发访问变为串行访问,消除了传统数据库串行控制的开销。】
Redis 的数据类型?
Redis 支持五种数据类型:string(字符串)、list(列表)、hash(哈希字典)、set(集合)、zset(有序集合)
。
我们实际项目中比较常用的是 string,hash 如果你是 Redis 中高级用户,还需要加上下面几种数据结构 HyperLogLog、Geo、Pub/Sub。
什么是Memcached ?
Memcached是一个自由开源的,高性能,分布式内存对象缓存系统。Memcached是一种基于内存的key-value存储,用来存储小块的任意数据(字符串、对象)。这些数据可以是数据库调用、API调用或者是页面渲染的结果。
Memcached简洁而强大。它的简洁设计便于快速开发,减轻开发难度,解决了大数据量缓存的很多问题。它的API兼容大部分流行的开发语言。本质上,它是一个简洁的key-value存储系统。
一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度、提高可扩展性。
特征
memcached作为高速运行的分布式缓存服务器,具有以下的特点。
- 协议简单
- 基于libevent的事件处理
- 内置内存存储方式
- memcached不互相通信的分布式
redis 与 memcached 的区别:
Redis 相比 Memcached 有哪些优势?
1. Memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰
富的数据类
2. Redis 的速度比 Memcached 快很多
3. Redis 可以持久化其数据(在数据量大又出现宕机时最能体现出来了)
一个字符串类型的值能存储最大容量是多少?
512M
Redis 提供两种持久化机制 RDB 和 AOF 机制:
RDB(Redis DataBase)持久化方式: 是指用数据集快照的方式半持久化模式)记录 redis 数据库的所有键值对,在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。
【RDB(Redis Database):指定的时间间隔能对你的数据进行快照存储。】
优点:
1、只有一个文件 dump.rdb,方便持久化。
2、容灾性好,一个文件可以保存到安全的磁盘。
3、性能最大化,fork 子进程来完成写操作,让主进程继续处理命令,所以是 IO最大化。使用单独子进程来进行持久化,主进程不会进行任何 IO 操作,保证了 redis的高性能)
4.相对于数据集大时,比 AOF 的启动效率更高。
缺点:
数据安全性低。RDB 是间隔一段时间进行持久化,如果持久化之间 redis 发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
AOF(Append-only file)持久化方式: 是指所有的命令行记录以 redis 命令请求协议的格式完全持久化存储)保存为 aof 文件。
【AOF(Append Only File):每一个收到的写命令都通过write函数追加到文件中。】
优点:
1、数据安全,aof 持久化可以配置 appendfsync 属性,有 always,每进行一次命令操作就记录到 aof 文件中一次。
2、通过 append 模式写文件,即使中途服务器宕机,可以通过 redis-check-aof工具解决数据一致性问题。
3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的 flushall))
缺点:
1、AOF 文件比 RDB 文件大,且恢复速度慢。
2、数据集大的时候,比 rdb 启动效率低
1. 定时删除:在设置键的过期时间的同时,创建一个定时器 timer). 让定时器在键的过期时间来临时,立即执行对键的删除操作。
2. 惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期,就返回该键。
3. 定期删除:每隔一段时间程序就对数据库进行一次检查,删除里面的过期键。至于要删除多少过期键,以及要检查多少个数据库,则由算法决定。
为什么 Redis 需要把所有数据放到内存中?
Redis 为了达到最快的读写速度将数据都读到内存中,并通过异步的方式将数据写入磁盘。所以 redis 具有快速和数据持久化的特征。如果不将数据放在内存中,磁盘 I/O 速度为严重影响 redis 的性能。在内存越来越便宜的今天,redis 将会越来越受欢迎。如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值。
Redis 如何做内存优化?
尽量使用 Redis 的散列表,把相关的信息放到散列表里面存储,而不是把每个字段单独存储,这样可以有效的减少内存使用。
【比如你的 web 系统中有一个用户对象,不要为这个用户的名称,姓氏,邮箱,密码 ,设置单独的 key,而是应该把这个用户的所有信息存储到一张散列表里面,再整体存储到 Redis】
都有哪些办法可以降低 Redis 的内存使用情况呢?
如果你使用的是 32 位的 Redis 实例,可以好好利用 Hash,list,sorted set,set
等集合类型数据,因为通常情况下很多小的 Key-Value 可以用更紧凑的方式存放到一起
redis的内存用完了会发生什么?
如果达到设置的上限,Redis 的写命令会返回错误信息(但是读命令还可以正常返回。)或者你可以将 Redis 当缓存来使用配置淘汰机制,当 Redis 达到内存上限时会冲刷掉旧的内容。
Redis 的同步机制了解么?
Redis 可以使用主从同步,从从同步。第一次同步时,主节点做一次 bgsave,
并同时将后续修改操作记录到内存 buffer,待完成后将 rdb 文件全量同步到复制
节点,复制节点接受完成后将 rdb 镜像加载到内存。加载完成后,再通知主节点
将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
是否使用过 Redis 集群,集群的原理是什么?
1)、Redis Sentinal 着眼于高可用,在 master 宕机时会自动将 slave 提升为master,继续提供服务。
2)、Redis Cluster 着眼于扩展性,在单个 redis 内存不足时,使用 Cluster 进行分片存储。
Redis 集群方案什么情况下会导致整个集群不可用?
有 A,B,C 三个节点的集群,在没有复制模型的情况下,如果节点 B 失败了,那么整个集群就会以为缺少 5501-11000 这个范围的槽而不可用。
Redisson、Jedis、lettuce 等等,官方推荐使用 Redisson。
设置密码:config set requirepass 123456
授权密码:auth 123456
Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念,Redis 集群有16384 个哈希槽,每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽,集群的每个节点负责一部分 hash 槽。
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有 N-1 个复制品.
Redis 并不能保证数据的强一致性,这意味这在实际中集群在特定的条件下可能会丢失写操作。
异步复制 16384个
Redis 集群目前无法做数据库选择,默认在 0 数据库。
使用 ping 命令。
1)事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
2)事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。
MULTI、EXEC、DISCARD、WATCH
EXPIRE【expire:到期,失效】 和 PERSIST 【persist:持续】命令
一个客户端运行了新的命令,添加了新的数据。Redi 检查内存使用情况,如果大于 maxmemory 的限制, 则根据设定好的策略进行回收。一个新的命令被执行,等等。所以我们不断地穿越内存限制的边界,通过不断达到边界然后不断地回收回到边界以下。如果一个命令的结果导致大量内存被使用(例如很大的集合的交集保存到一个新的键),不用多久内存限制就会被这个内存使用量超越。
Redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。
相关知识:
Redis 提供 6 种数据淘汰策略:
使用 keys 指令可以扫出指定模式的 key 列表。
弊端:如果这个 redis 正在给线上的业务提供服务,那使用 keys 指令会导致线程阻塞(因为redis是单线程的)。
解决:使用 scan 指令,scan 指令可以无阻塞的提取出指定模式的 key 列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用 keys 指令长。
先拿 setnx 来争抢锁,抢到之后,再用 expire 给锁加一个过期时间防止锁忘记了释放。如果在 setnx 之后执行 expire之前进程意外 crash 或者要重启维护了,这个时候可以考虑同时把 setnx 和expire 合成一条指令来用。
Redis 分布式锁其实就是在系统里面占一个“坑”,其他程序也要占“坑”的时候,占用成功了就可以继续执行,失败了就只能放弃或稍后重试。
占坑一般使用 setnx(set if not exists)指令,只允许被一个程序占有,使用完调用 del 释放锁。
Redis 分布式锁不能解决超时的问题,分布式锁有一个超时时间,程序的执行如果超出了锁的超时时间就会出现问题。
《Redis缓存处理问题》
缓存穿透:指查询一个一定不存在的数据,由于缓存是不命中时需要从数据库查询,查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,造成缓存穿透。
解决方案:最简单粗暴的方法如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们就把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。
MQ的消息是存放在内存或者磁盘中的,在缩减集群数量时,必须要迁移节点的数据。增加节点时,要重新配置集群。这么看来是无法平滑缩容和扩容的。
incr 让当前键值以 1 的数量递增,并返回递增后的值
incrby 可以指定参数一次增加的数值,并返回递增后的值
decr 让当前键值以 1 的数量递减 并返回递减后的值
decrby 可以指定参数一次递减的数值,并返回递减后的值
incrbyfloat 可以递增一个双精度浮点数
append 作用是向键值的末尾追加 value。如果键不存在则将该键的值设置为 value。返回值是追加后字符串的总长度。
mget/mset 作用与 get/set 相似,不过 mget/mset 可以同时获得/设置多个键的键值
del 根据 key 来删除 value
flushdb 清除当前库的所有数据
hset 存储一个哈希键值对的集合
hget 获取一个哈希键的值
hmset 存储一个或多个哈希是键值对的集合
hmget 获取多个指定的键的值
hexists 判断哈希表中的字段名是否存在 如果存在返回 1 否则返回 0
hdel 删除一个或多个字段
hgetall 获取一个哈希是键值对的集合
hvals 只返回字段值
hkeys 只返回字段名
hlen 返回 key 的 hash 的元素个数
lpush key value 向链表左侧添加
rpush key value 向链表右侧添加
lpop key 从左边移出一个元素
rpop key 从右边移出一个元素
llen key 返回链表中元素的个数 相当于关系型数据库中 select count(*)
lrange key start end lrange 命令将返回索引从 start 到 stop 之间的所有元素。Redis的列表起始索引为 0。
lrange 也支持负索引 lrange nn -2 -1 如 -1 表示最右边第一个元素 -2 表示最右边第二个元素,依次类推。
lindex key indexnumber 如果要将列表类型当做数组来用,lindex 命令是必不可少的。
lindex 命令用来返回指定索引的元素,索引从 0 开始 如果是负数表示从右边开始计算的索引,最右边元素的索引是-1。
Lset key indexnumber value 是另一个通过索引操作列表的命令,它会将索引为index 的元素赋值为 value。
sadd key value 添加一个 string 元素到,key 对应的 set 集合中,成功返回 1,如果元素已经在集合中返回 0
scard key 返回 set 的元素个数,如果 set 是空或者 key 不存在返回 0
smembers key 返回 key 对应 set 的所有元素,结果是无序的
sismember key value 判断 value 是否在 set 中,存在返回 1,0 表示不存在或者 key不存在
srem key value 从 key 对应 set 中移除给定元素,成功返回 1,如果 value 在集合中不存在或者 key 不存在返回 0
zadd key score value 将一个或多个 value 及其 socre 加入到 set 中
zrange key start end 0 和-1 表示从索引为 0 的元素到最后一个元素(同 LRANGE 命令相似)
zrange key 0 -1 withscores 也可以连同 score 一块输出,使用 WITHSCORES 参数
zremrangebyscore key start end 可用于范围删除操作
ping 测试 redis 是否链接 如果已链接返回 PONG
echo value 测试 redis 是否链接 如果已链接返回 echo 命令后给定的值
keys * 返回所有的 key 可以加*通配
exists key 判断 string 类型一个 key 是否存在 如果存在返回 1 否则返回 0
expire key time(s) 设置一个 key 的过期时间 单位秒。时间到达后会删除 key 及 value
ttl key 查询已设置过期时间的 key 的剩余时间 如果返回-2 表示该键值对已经被删除
persist 移除给定 key 的过期时间
select dbindex 选择数据库(0-15)
move key dbIndex 将当前数据库中的 key 转移到其他数据库中
dbsize 返回当前数据库中的 key 的数目
info 获取服务器的信息和统计
flushdb 删除当前选择的数据库中的 key
flushall 删除所有数据库中的所有 key
quit 退出连接