Saas项目技能点总结~~~~

最新推荐文章于 2023-11-01 17:04:05 发布
最新推荐文章于 2023-11-01 17:04:05 发布
阅读量926 收藏 1
点赞数
文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lierwe/article/details/109664805
版权

1、Redis

特点：

  • 速度快[存储在内存中]
  • 支持丰富数据类型
  • 丰富的特性
    • 订阅发布 Pub / Sub 功能
    • Key 过期策略
    • 事务
    • 支持多个 DB
    • 计数
  • 持久化存储
    • Redis 提供 RDB 和 AOF 两种数据的持久化存储方案，解决内存数据库最担心的万一 Redis 挂掉，数据会消失掉。

redis的应用场景

• 缓存（数据查询、短连接、新闻内容、商品内容等等）
　　　　　　　　• 聊天室的在线好友列表
　　　　　　　　• 任务队列。（秒杀、抢购、12306等等）
　　　　　　　　• 应用排行榜
　　　　　　　　• 网站访问统计
　　　　　　　　• 数据过期处理（可以精确到毫秒
　　　　　　　　• 分布式集群架构中的session分离

常用数据结构

基础：

  • 字符串 String
  • 哈希Hash
  • 列表List【有序】
  • 集合Set【唯一无序】
  • 有序集合 SortedSet【zset】

概念：

ridis:全称 Remote Dictionary Server ，是一个基于内存的高性能 Key-Value 数据库。

非关系型数据库：作为关系型数据库的良好补充。

分类特点代表产品
键值存储数据一般存在内存中，读写速度快(10w/s)，适合作为缓存服务 当成map即可redis
文档型数据库数据结构要求不严格，适合存储结构不确定或者价值较低的数据mongodb
列存储数据库查找速度快，更容易进行分布式扩展，适合作为文件存储服务Hbase
图形数据库使用“图结构”进行存储，适合做社交网络计算等等Neo4j

* redis持久化【RDB、AOF】

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。Redis支持两种方式的持久化（RDB和AOF），可以同时使用。

  • RDB(快照方式)【默认方式】

    在一定的间隔时间中，检测key的变化情况，然后持久化数据

    .文件名称:dump.rdb

    rdb默认的快照规则:在redis.windwos.conf文件

    save 900 1 当15分钟之内有1个key发生变化就拍照

    save 300 10 当300秒之内有10个key发生变化就拍照

    save 60 10000 当60秒之内有1w个key发生变化就拍照

    重启服务器后,默认是从rdb文件中恢复数据到内存中

  • AOF(追加命令到文件中),需要手动开启的,文件名称:appendonly.aof

    以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

    可以每一次命令操作后，持久化数据

    appendfsync always 每执行一个命令,就会把命令追加到文件中,和关系型数据库相似

    appendfsync everysec 每一秒钟,把所有的操作命令追加到文件中

    appendfsync no 不同步,等同于rdb

    启动的时候需要指定配置文件启动，修改配置文件redis.windows.conf中 appendonly no 将他的值改成yes,重启服务器就生效,

    虽然开启了aof,但是rdb依然能用.只不过是,当服务器重启的时候,从aof文件将数据恢复到内存中.

当我们正常关闭redis服务器的时候,他会通过不同的方式将内存中的数据保存到硬盘文件中.再次启动的时候,会去文件中把数据恢复到内存中.

若我们把redis作为缓存使用,建议使用rdb方式,高效; 若数据需要不时的持久化,建议使用aof方式.

缓存是允许有数据丢失.

  • bg save 做镜像全量持久化，AOF 做增量持久化。因为 bgsave 会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要 AOF 来配合使用。
  • 在 Redis 实例重启时，会使用 bgsave 持久化文件重新构建内存，再使用 AOF 重放近期的操作指令来实现完整恢复重启之前的状态。
  • 对方追问那如果突然机器掉电会怎样？
  • 取决于 AOF 日志的属性的配置，如果不要求性能，在每条写指令时都 sync 一下磁盘文件，就不会丢失数据。但是在高性能的要求下每次都 sync 是不现实的，一般都使用定时sync ，比如 1 秒 1 次，这个时候最多就会丢失 1 秒的数据。
  • 对方追问 bgsave 的原理是什么？
  • 你给出两个词汇就可以了，fork 和 cow 。
  • fork 是指 Redis 通过创建子进程来进行 bgsave 操作。
  • cow 指的是 copy on write ，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据。

Redis 单线程模型也能效率这么高

  1. 纯内存操作。
  2. 核心是基于非阻塞的 IO 多路复用机制。
    • IO多路复用就是只有单个线程，通过跟踪每个IO流的状态，来管理多个IO流
  3. 单线程反而避免了多线程的频繁上下文切换问题。
    • Redis 利用队列技术，将并发访问变为串行访问，消除了传统数据库串行控制的开销
  4. Redis 全程使用 hash 结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩
    表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

如何使用 Redis 实现分布式锁？

方案一：set 指令

  • 先拿 setnx 来争抢锁，抢到之后，再用 expire 给锁加一个过期时间防止锁忘记了释放。
  • 对于意外 crash 或者要重启维护： 可以同时把 setnx 和 expire 合成一条指令来用的！

方案二：redlock

  • set 指令的方案，适合用于在单机 Redis 节点的场景下，在多 Redis 节点的场景下，会存在分布式锁丢失的问题。
    所以，Redis 作者 Antirez 基于分布式环境下提出了一种更高级的分布式锁的实现方式：Redlock 。

对比 Zookeeper 分布式锁

  • 从可靠性上来说，Zookeeper 分布式锁好于 Redis 分布式锁。
  • 从性能上来说，Redis 分布式锁好于 Zookeeper 分布式锁。

集群

  • 主从复制
  • 哨兵模式

jedis

​ jedis就是集成了redis的一些命令操作，封装了redis的java客户端。提供了连接池管理【jedis连接资源的创建与销毁是很消耗程序性能】。一般不直接使用jedis，而是在其上在封装一层，作为业务的使用。如果用spring的话，可以看看spring 封装的 redis [Spring Data Redis]

​ 在官方网站里列一些Java的客户端，有Jedis、Redisson、Jredis、JDBC-Redis、等其中官方推荐使用Jedis和Redisson。 在企业中用的最多的就是Jedis

jedis对redis 相当于 jdbc对关系型数据库

2、ES；

3、dubbo

SOA:即面向服务的架构。有如下几个特点：分布式、可重用、扩展灵活、松耦合。

RPC:远程调用 ,是一个过程,不是一种技术.例如a服务器调用b服务器的过程. 例如比较出名的RPC框架有:dubbo和spring cloud(项目二中应用)

dubbo的工作流程是

  • 使用zookeeper做注册中心
  • 提供者启动之后,就会向注册中心注册服务,服务是通过dubbo的注解@Service暴露出去的
  • 消费者启动之后,就会向注册中心订阅自己需要那些服务,这个是通过duobbo的注解@Reference体现的
  • 注册中心会将这些服务提供者的信息返回给消费者
  • 当消费者需要调用提供者的时候,默认会随机从这些提供者拿出来一个（）,然后远程调用它的方法即可.

在dubbo中还有一个监控中心,可以记录下消费者和提供者的一些信息,也可以设置权重和负载均衡的策略

相关配置

提供者：dubbo应用名称,注册中心地址,协议端口和注解支持

消费者：dubbo应用名称,注册中心地址和注解支持

​ 【额外的其他配置（check属性检查有无对应的提供者，推荐false）（retries属性重试次数）（timeout属性超时时间）】

1.提供者的配置【在对应的service的配置文件中】

如：applicationContext_company_provider.xml

 <!--dubbo的配置 都用阿里的-->
    <!--注册中心地址-->
    <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
    <!--应用的名称-->
    <dubbo:application name="dubbo_provider"/>
    <!--协议和端口号 name:协议的名称 port:端口号,建议从20880开始写-->
    <dubbo:protocol name="dubbo" port="20880"/>
    <!--注解支持-->
    <dubbo:annotation package="cn.lee.service"/>

2.消费者的配置【web层的springmvc.xml】

<!--dubbo消费者配置-->
    <!--注册中心-->
    <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
    <!--应用名称-->
    <dubbo:application name="export_web_manager"/>
    <!--注解支持-->
    <dubbo:annotation package="cn.lee.web"/>
    <!--其他配置
            check属性:启动的时候是否要检查有无对应的提供者.默认值是true.开发中一般设置为false
            retries属性:重试的次数,一般设置为0次
            timeout属性:连接的超时时间,超过此时间就会报错 单位:毫秒-->
    <dubbo:consumer check="false" retries="0" timeout="3000"/>

监控中心dubbo-admin

查看有哪些提供者和消费者,查看调用的次数(需要配置),调节提供者的权重(负载均衡)

SOA和微服务得区别

SSM传统项目：并发压力有限 tomcat8.0 （1000）

Dubbo：基于RPC远程调用的长连接，不是Http协议的（每次发送内容没有head头信息），效率高

​ 1.基于长连接

​ 2.效率高

​ 3.必须是Java的

zookeeper注册中心一般是奇数，因为有选举机制（偶数效率低）

SpringCloud的注册中心

SpringCloud：基于Http远程调用的短链接，效率低，兼容性

​ 1.基于http短链接

​ 2.相比dubbo效率低

​ 3.兼容性好

Http协议：head（请求方式，json/text） body，http协议是基于TCP协议的

TCP调用：三次握手，四次挥手

Socket：套接字是指通过ip地址+端口号，在流中发送和接收数据的这种交互方式

长连接：握手后不断开，服务器可以找到客户端

短链接：客户端发起请求，服务器响应后，断开本次请求，服务器无法再次找到客户端

SpringCloud 和Dubbo 的区别（必会）

SpringCloud：Spring 公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案（微服务生态）。
Dubbo：阿里巴巴开源的 RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

4、echarts

我们只需要找到想要的图形,将它的option复制过来,然后让后台组织对应的数据即可.

对于基本图形来说,需要的数据就是json数组,每个json对象只需要name和value两个属性即可

要求我们的controller只需要返回List,使用@ResponseBody将list转成json数组即可.

再次我使用ajax方式去查询页面上需要的数据.

5、POI报表注意事项

1.POI 的介绍

POI是用JAVA语言编写的免费的开源的跨平台API， 可以对微软的word、Excel、PPT进行操作。

2.Excel 报表导出流程：

  1. 创建工作簿Workbook(HSSFWorkbook)<工作簿这块我们需要注意一个问题，普通处理Excel 我们分为 Excel03(HSSF)版和 07(XSSF)版本以上，对于大数据处理我们使用SXSSF，比如一个Excel有 40 多列>
  2. 创建工作表sheet(createSheet())
  3. 设置一些参数(sheet.set***)设置列宽
  4. 要设置标题、标题行、设置行高(setHeightInPoints())，设置单元格对象，设置对象里边的内容。还有就是合并单元格，横向合并单元格
  5. 数据填充
  6. 实现文件下载，导出到制定路径

3.百万级数据导出

​ 涉及的数据量比较大，我们这里采用 POI 给我们提供的支持07 版本的 SXSSFWork 对象实现导入导出， 但是不能使用模板打印，不能使用太多的样式

​ POI里边提供了两种模式， 用户模式(系统默认)和事件模式。

这两个的区别是：用户模式:相当于xml中dom解析,一次性将所有的数据读取到内存中,再处理

​ 事件模式:相当于xml中sax解析,逐行扫描解析,大量数据的话不会造成oom异常【内存溢出】【用于这种百万数据导出导入】

使用事件模式解析的步骤:

  1. 创建一个公用的解析器【Excel 解析器】[公司提供]

  2. 创建一个行解析器(自己创建)【sheet解析器】【是基于 SAX 解析】

6、MQ的使用模式、选型、消息一致性、消息丢失等问题的处理。

相关概念

RabbitMQ 是一款开源的，Erlang编写的，基于 AMQP协议的，消息中间件。

消息队列中间件是分布式系统中重要的组件，主要解决**应用解耦，异步消息，流量削锋**等问题，实现高 性能，高可用，可伸缩和最终一致性架构。

  • 消费者 consumer
  • 生产者 produce

queues队列 ：这个东西就是一个队列，一个存储消息的队列，并且可以持久化，而且这个队列中的消息可以被消费，如果出现死信则是死信队列，死信队列也是可以被处理的

常见的消息中间件

  • RabbitMQ :阿里 使用广泛
  • RocketMQ :阿里(上一代)
  • ActiveMQ : apache (特点:爱丢数据 java,使用较少)
  • kafka : apache 属于大数据生态圈 特点:高吞吐

规范:

  • JMS:java的消息服务规范 javaee规范之一 代表作:ActiveMQ
  • AMQP: 不区分语言消息中间件的协议 代表作:RabbitMQ

RabbitMQ有什么缺点？

  • 降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低。
  • 增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。

如何保证RabbitMQ 高可用？

​ 搭建 RabbitMQ 集群。一般小型，中型项目搭建3 台够用了。数据量在500万内。

如何保证RabbitMQ 消息可靠传输？

消息不可靠的情况可能是消息丢失，劫持等原因。丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息。

  • 生产者丢失消息
    从生产者弄丢数据这个角度来看，RabbitMQ提供 transaction和 confirm模式来确保生产者不丢消息。
    • transaction模式：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点，吞吐量下降。
    • confirm模式：一旦 channel 进入 confirm 模式，所有在该信道上发布的消息都将会被指派一个唯一的 ID（从 1 开始），一旦消息被投递到所有匹配的队列之后。RabbitMQ 就会发送一个ACK 给生产者（包含消息的唯一 ID），这就使得生产者知道消息已经正确到达目的队列了.如果rabbitMQ没能处理该消息，则会发送一个 Nack消息给你，你可以进行重试操作。
  • 消息队列丢数据【项目中使用的】
    ``消息持久化`。处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和 confirm 机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个 Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ 阵亡了，那么生产者收不到 Ack 信号，生产者会自动重发。那么如何持久化呢？

​ 这里顺便说一下吧，其实也很容易，就下面两步：

​ 1.将 queue 的持久化标识 durable 设置为 true,则代表是一个持久的队列。

​ 2.发送消息的时候将 deliveryMode=2。这样设置以后，即使rabbitMQ 挂了，重启后也能恢复数据。

  • 消费者丢失消息 【改为手动回执】
    消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！消费者在收到消息之后，处理消息之前，会自动回复 RabbitMQ 已收到消息。如果这时处理消息失败，就会丢失该消息。
    解决方案：处理消息成功后，手动回复确认消息。

RabbitMQ消息丢失解决方案

消息持久化、设置为自动回执

  • 消息持久化
    Exchange 设置持久化：durable:true。
    queue 设置持久化；Message 持久化发送。
  • ACK 确认机制
    消息发送确认。消息接收手动确认 ACK

RabbitMQ宕机了怎么处理

持久化还怕宕机=

RabbitMQ提供了持久化的机制，将内存中的消息持久化到硬盘上，即使重启 RabbitMQ，消息也不会丢失。
持久化队列和非持久化队列的区别是:

​ 持久化队列会被保存在磁盘中，固定并持久的存储，当 Rabbit 服务重启后，该队列会保持原来的状态在 RabbitMQ
中被管理，

​ 而非持久化队列不会被保存在磁盘中，Rabbit 服务重启后队列就会消失。非持久化比持久化的优势就是，由于非持久化不需要保存在磁盘中，所以使用速度就比持久化队列快。即是非持久化的性能要高于持久化。
而持久化的优点就是会一直存在，不会随服务的重启或服务器的宕机而消失。

如何解决分布式事务问题

  • 2PC：两阶段提交【性能差】
  1. 执行阶段：
    当创建订单时，向所有微服务发送消息,可以开始执行了,执行成功后，不直接提交,而是返回一个消息告诉我,执行成功还是执行失败。
  2. 第二阶段：
    如果所有人都执行成功,再发一个消息,你们可以提交了；如果第一阶段有人执行失败,你就告诉所有人都回滚。
    缺点：当锁定的表很多时,性能差。
  • TCC：补偿性事务(一般采用) try-confirm-concel
    每个服务执行完后都提交,集中返回给自己,如果都执行成功了那就不管如果提交失败,就采用失败服务的补偿方法去补偿,但若补偿方法也失败,那你还需要进行重试写重试方法或者人工介入。
    优缺：解决了性能问题,但是业务复杂,写一个事务还需要写补偿方法
  • 异步确保：利用 mq 实现分布式事务。

**消息的两种模式

  • 队列模式(点对点)
    • 数据不丢失
    • 同一条数据只能有一个消费者消费
  • 订阅模式(广播)
    • 数据可能丢失
    • 同一条数据可以有多个消费者消费

rabbitmq基于以上两种模式进行扩展:

  • 队列模式(点对点)
    • 一般基本模式【一个生产者，一个消费者】
      • 生产者 ：向队列发送消息
      • 消费者 ：从队列中获取消息
    • 工作(work)模式【一个生产者，多个消费者】[Work发送后，可以多个消费者处理生产出来的消息，消息被消费后消失]
      • 生产者 ：向队列发送消息
      • 消费者 ：多个消费者轮询的方式获取消息
        • 默认是平分的，设置basicQos(1)实现能者多劳
        • 设置每个消费者同时只能处理一条消息channel.basicQos(1);

角色功能:

  • 生产者：向队列发送消息
  • 消费者：需要绑定队列
  • 队列：存储生产者的消息

  • 订阅模式(广播)【一个生产者，多个消费者】

    • 一般广播模式-fanout【Fanout发送后，全部消费者收到消息】

      • 生产者 ：确定交换机已声明后，向交换机发送消息
      • 消费者 ：确定队列已绑定交换机后，从队列获取消息
        • channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, “”);

    • 路由【定向】模式-direct【Direct发送后，路由相同的消费者收到消息】

      • 生产者 ：确定交换机已声明后，向交换机发送消息，发送时指定路由

        • 放信息的时候就需要指定key

      • 消费者 ：确定队列已绑定交换机并在绑定时指定路由，从队列获取消息

        • channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, “insert”);

        • 例：队列1key:buy，对应的消费者只能接受buy信息

          ​ 队列2key:back 对应的消费者接受back信息

    • 主题模式-topic【Topic发送后，路由相同的消费者收到消息，不过可以采用通配符的方式】

      • 生产者 ：确定交换机已声明后，向交换机发送消息，发送时指定路由

        • 放信息的时候就需要指定key buy.a

      • 消费者 ： 确定队列已绑定交换机并在绑定时指定路由，从队列获取消息

        • channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, “item.*”);

        • 例：队列1key: buy.*，对应的消费者1可以收到buy信息，不能接受back信息

          队列2key：​back.* buy.*，对应的消费者2可以接受back信息，能接受back信息

  • key的匹配操作,一般使用.隔开key
    支持两种通配符
    ①buy.* :一层目录任意字符 匹配 buy.a buy.b; 但是buy.a.a 匹配不到
    ②buy.# :任意层目录任意字符 匹配 buy.a buy.b buy.a.a

角色功能:

  • 生产者：向交换机发送消息
  • 消费者：需要绑定队列
  • 交换机：发给绑定过的所有队列
  • 队列：需要绑定到交换机

消息回执

简称ACK

有两种方式:

  1. 自动回执:一旦消费者收到信息,马上发送回执.

  2. 手动回执:需要在代码中通过api发送回执,对消息要求比较高的时候建议使用手动回执

问题：

  1. 解决消息丢失 ：：

    ①开启持久化

    交换机定义消息队列,durable:是否持久化，如果想在RabbitMQ退出或崩溃的时候，不会失去所有的queue和消息，需要同时标志队列(queue)和交换机(exchange)是持久化的，即rabbit:queue标签和rabbit:direct-exchange中durable=true

    ②消费者手动确认消息【设置消息回执为手动】

  2. 避免消息堆积：：可以设置多消费者监听，实现消息争抢

  3. 消息有序性：：要顺序就要放弃效率，确定队列只有单一消费者

  4. 消息重复：：在消费端通过业务判断是否已执行，比如将处理过的消息在数据库做标识处理

6.定时任务调度框架Quartz

①Quartz框架

基于给定的时间点、给定的时间间隔、给定的执行次数自动执行的任务

除此之外:

  • spring task
  • jdk中timer

②核心组件

job:任务

detail:任务详情,具体的描述任务信息

trigger:触发器,包含任务详情和触发的时间 【七子表达式】

schdule:调度器,调度所有的触发器

7.Jasper Report（PDF文件导出技术）

​ 如果使用Jasper Report技术进行pdf文件导出，可以使用Jaspersoft Studio工具（软件）设计pdf文件的模板

其他PDF技术：

  • iText PDF
  • Openoffice

JasperReport 的生命周期

设计（Design）阶段、执行（Execution）阶段以及输出（Export）阶段。

  1. 设计阶段就是使用Jaspersoft Studio工具创建模板，模板创建完成我们保存为 JRXML 文件（JR 代表JasperReports）,其实就是一个 XML 文件。
  2. 执行阶段编译成可执行的二进制文件(即.Jasper 文件)结合数据进行执行，进行数据填充。
  3. 输出阶段（Export）：数据填充结束，可以指定输出为多种形式的报表。

如何使用

  1. 导入坐标，
  2. 引入模板，把编译好的模板引入到当前工程中。
  3. 配置控制器方法(1.加载模板文件， 2.构建文件输入流； 3.创建 JasperPrint 对象；4.写入 pdf 文档输出 )【按照笔记搞】

8.Zookeeper

​ ZooKeeper是一种为分布式应用所设计的高可用.高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于 ZooKeeper 的开源特性，后来我们的开发者在分布式锁的基础上， 摸索了出了其他的使用方法： 配置维护.组服务.分布式消息队列.分布式通知/协调等。

Zookeeper的核心是什么？

​ Zookeeper的核心是**原子广播**，这个机制保证了各个 Server 之间的同步。

实现这个机制的协议叫做Zab 协议。Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 Server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 Server 具有相同的系统状态。

Zookeeper中的每个 Server有几种状态？

每个 Server 在工作过程中有三种状态：
LOOKING：当前 Server 不知道 leader 是谁，正在搜寻
LEADING：当前 Server 即为选举出来的 leader
FOLLOWING：leader 已经选举出来，当前 Server 与之同步

为什么zookeeper 集群的数目，一般为奇数个？

  1. 容错
    由于在增删改操作中需要半数以上服务器通过。

​ n(奇数) 台服务器和 n+1台服务器都最多允许 相同的（n-1）/2 台服务器挂掉，才能维持半数以上服务器通过。那多一台服务器不是钱？？？

  1. 防脑裂【放至有多个leader 服务器】

Zookeeper 分布式锁的应用场景

​ 在分布式锁服务中，有一种最典型应用场景，就是通过对集群进行Master选举，来解决分布式系统中的单点故障。什么是分布式系统中的单点故障：通常分布式系统采用主从模式，就是一个主控机连接多个处理节点。主节点负责分发任务，从节点负责处理任务，当我们的主节点发生故障时，那么整个系统就都瘫痪了，那么我们把这种故障叫作单点故障。

  • 传统解决方案

      传统方式是采用一个备用节点，这个备用节点定期给当前主节点发送 ping包，主节点收到 ping 包以后向备用节点发送回复 Ack，当备用节点收到回复的时候就会认为当前主节点还活着，让他继续提供服务。
	当主节点挂了，这时候备用节点收不到回复了，然后他就认为主节点挂了接替他成为主节点但是这种方式就是有一个隐患，也就是说我们的主节点的并没有挂，只是在回复的时候网络发生故障，这样我们的备用节点同样收不到回复，就会认为主节点挂了，然后备用节点将他的Master实例启动起来，这样我们的分布式系统当中就有了两个主节点也就是-双 Master，出现 Master以后我们的从节点就会将它所做的事一部分汇报给了主节点，一部分汇报给了从节点，这样服务就全乱了。

  • Zookeeper解决方案：
    Master启动：
    在引入了 Zookeeper以后我们启动了两个主节点，“主节点-A"和"主节点-B"他们启动以后，都向 ZooKeeper 去注册一个节点。我们假设"主节点-A"所注册地节点是"master-00001”， “主节点-B"所注册的节点是"master-00002”，注册完以后进行选举，编号最小的节点将在选举中获胜获得“锁”并且成为主节点，也就是我们的"主节点-A"将会获得“锁”成为主节点，然后"主节点-B"将被阻塞成为一个备用节点。那么，通过这种方式就完成了对两个 Master 进程的调度。

    ⑴ Master故障
    如果"主节点-A"挂了，这时候他所注册的节点将被自动删除，ZooKeeper 会自动感知节点的变化，然后再次发出选举，这时候"主节点-B"将在选举中获胜，替代"主节点-A"成为主节点。

    ⑵ Master恢复
    如果“主节点-A”恢复了，他会再次向 ZooKeeper注册一个节点，这时候他注册的节点将会是"master-00003"，ZooKeeper会感知节点的变化再次发动选举，由于编号最小的节点将在选举中获胜获得“锁”并且成为主节点，这时候"主节点-B"在选举中会再次获胜继续担任"主节点"，"主节点-A"会担任备用节点。

9.WebService 技术

项目开发中使用的是基于 webService 的一套框架CXF，Cxf 是基于 SOA 总线结构，依靠 spring 完成模块的集成，实现 SOA 方式。底层就是基于servlet开发的

灵活的部署: 可以运行在 Tomcat,Jboss,Jetty(内置),weblogic 上面。

webService的三大规范是什么？

分别指的是 JAX-RS，JAX-WS，JAX-WS&SAAJ(废弃)

JAX-RS:

  • http发送符合restful风格请求,服务器处理.返回内容可以是xml或者json

jax-ws:(了解)

  • http请求发送的纯xml数据,服务器响应的回来的数据也是xml.xml是有约束(soap)
  • 也有人称之为soap协议

webService的三要素是什么？

SOAP，WSDL，UDDI

  • SOAP: 基于 HTTP 协议，采用 XML 格式，用来传递信息的格式。【基于XML的协议.规范】
  • WSDL: 用来描述如何访问具体的服务。【对webservice的应用一个描述信息】
  • UDDI: 用户自己可以按 UDDI 标准搭建 UDDI 服务器，用来管理，分发，查询 WebService 。其他用户可以 自己注册发布 WebService 调用。
小猿猴~
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
【本人秃顶程序员】Kafka 的 Lag 计算误区及正确实现
本人秃顶程序员的博客
01-11 433
←←←←←←←←←←←← 快，点关注！ 前言 消息堆积是消息中间件的一大特色，消息中间件的流量削峰、冗余存储等功能正是得益于消息中间件的消息堆积能力。然而消息堆积其实是一把亦正亦邪的双刃剑，如果应用场合不恰当反而会对上下游的业务造成不必要的麻烦，比如消息堆积势必会影响上下游整个调用链的时效性，有些中间件如RabbitMQ在发生消息堆积时在某些情况下还会影响自身的性能。对于Kafka而言，虽然消息堆...
整理资料
Strive_0902的博客
10-03 425
云计算的架构： 1 software as a service 软件即服务，简称SaaS，这层的作用是将应用主要以基于Web的方式提供给客户；由于SaaS层离普通用户非常接近，所以在SaaS层所使用到的技术，大多耳熟能详，下面是其中最主要的五种：由于通用性和较低的学习成本，大多数云计算产品都会比较倾向HTML 、JavaScript和CSS这对黄金组合。 2 Platform as a S...
Spring Kafka：@KafkaListener 单条或批量处理消息
程序猿DD
05-03 943
来源：csdn.net/ldw201510803006/article/details/116176711消息监听容器1、KafkaMessageListenerContainer由spring提供用于监听以及拉取消息，并将这些消息按指定格式转换后交给由@KafkaListener注解的方法处理，相当于一个消费者；看看其整体代码结构：图片可以发现其入口方法为doStart...
SaaS可配置性设计要点
一朝风月
11-01 303
考虑到系统SaaS需求，就成熟的SaaS应用而言，元数据服务是为用户提供定制和配置应用、满足其特定需求的主要手段。
SAAS 开发技术项目实验（一）
数据攻城狮的博客
11-09 894
文章目录安装Docker禁用防火墙与 SELinux设置网络设置主机名设置时区安装必要的包设置 Docker CE 稳定版的仓库地址安装指定版本的 Docker CE安装完毕，查看版本启动 Docker运行 hello-world 镜像来验证 Docker CE 已经正常安装配置 Docker 开机自动启动开启 Docker 远程访问通过-H 选项指定要连接的远程主机 安装Docker 准备一台实验用计算机。推荐使用 VMware Workstation 虚拟机软件创建一台运行 CentOS 7 操作系统的
文件管理saas应用 ui .sketch素材下载
04-20
总结来说，文件管理SaaS应用UI设计关乎用户体验和效率，Sketch作为强大的设计工具，能帮助我们实现这一目标。通过下载并研究document-management-drive-mdafzal.sketch素材，我们可以深入了解UI设计的最佳实践，提升...
前端全栈进阶 Nextjs打造跨框架SaaS应用
最新发布
05-06
2. **服务端能力要求：** 需要具备一定的服务端开发技能。建议学习Node.js等相关技术。 3. **部署复杂度：** 对于初学者来说可能不太友好。可以参考官方文档或者社区教程来逐步解决部署问题。 #### 五、案例分析 ...
如何打破薪资瓶颈-50W年薪运维岗位技能剖析
03-18
总结起来，打破薪资瓶颈的50W年薪运维岗位技能包括：扎实的Linux基础，监控报警能力，自动化运维工具的运用，强大的故障排查和编程技能，对云计算的深入理解，以及优秀的团队协作和项目管理能力。只有不断学习和实践...
SpeechTherapy:Ruby on Rails 项目 - EDx SaaS 169.1x
06-22
本篇文章将深入探讨一个名为“SpeechTherapy”的项目，这是在EDx平台上SaaS 169.1x课程中作为教学实例的一部分。通过这个项目，我们将探讨如何利用Rails进行实际的Web应用开发，并结合JavaScript增强用户体验。 ...
技术面试必备基础知识 _面试总结_
09-30
这些知识点是面试中经常被问到的，同时也是作为一名合格的IT从业者必须掌握的基本技能。深入理解和熟练运用这些概念，将大大增加你在技术面试中脱颖而出的可能性。在准备过程中，不仅要理解理论，还要通过实践项目和...
基于golang go语言Gin框架开发的在线客服SAAS系统.zip
04-01
总结，基于Go语言Gin框架开发的在线客服SAAS系统结合了Go语言的高性能和Gin框架的易用性，为开发高并发、稳定可靠的在线客服系统提供了有效解决方案。通过这样的毕业设计或课程作业，学生可以深入理解后端开发的各个...
产品经理SAAS实施的“七宗罪”.pdf
12-17
【产品经理SAAS实施的“七宗罪”】 SAAS（Software as a Service）实施过程中，产品经理需要面对诸多挑战，这些挑战有时可能成为成功的阻碍。...只有这样，才能确保SAAS项目的成功实施，为企业带来真正的价值。
十堰实习总结.docx
03-03
对于即将步入职场的学生而言，这样一份详尽的实习总结不仅有助于巩固已学知识、提升技能水平，同时也是对未来职业发展路径的重要规划和思考。希望每位经历过实习的人都能从中获得宝贵的经验和启示。
新员工学习总结范文.doc
03-05
以下是我作为一名新员工的学习总结，旨在分享我在IT领域的学习体验和收获。 首先，我对公司的业务流程和技术架构进行了深入的理解。每个公司都有其独特的业务模式和技术栈，我通过阅读相关文档、参与内部培训以及与...
Kafka概念和基本架构概述
chuanchengdabing的博客
11-04 525
概念和基本架构 一、Kafka介绍 Kafka是最初由 Linkedin 公司开发，是一个 分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统）。常见可以用于web/nginx日志、访问日志，消息服务等等。 Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是： 日志收集系统 消息系统 Kafka主要设计目标如下： 1. 以时间复杂度为O(1)的方式提供消息持久化能力，即使对 TB级 以上数
Kafka概念-架构
qq_43590904的博客
10-01 400
Kafka概念-架构 目录 消息队列的好处 消息队列模式 什么是 Kafka Kafka整体架构及解析 消息队列的好处 解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所 以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。(注意消息重复消费) 缓冲 有助于控制和优化数据流经过系统的速度,解决生产者和消费者处理消息能力不一致的问题 灵活性 &
kafka中consumer和partition的对应关系
zzhongcy的专栏
01-06 940
kafka
kafka
小贺同学
12-07 2281
kafka 定义 1.1 kafka 是分布式的基于发布/订阅模式的消息中间件，主要应用在大数据领域。 kafka主要还是主动拉取数据 1.2 消息队列的两种模式 1）点对点（ 一对一 消费者主动拉取数据 消息收到后消息清除 ） 消息生产者发送消息到队列 ，消费者从队列中获取消息。 消息被消费后 队列中不在有存储 所以消息消费者不可能消费到已经被消费的消息 2）发布/订阅模式 (一对多 消费者消费数据后不会清除数据 支持主动拉取数据和推送 两种消费方式 ) ​ 消息生产者将消息发送到topic中，同时
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值