原文作者：刘望舒
文章转载自：https://juejin.im/post/58d15f1044d90400691834d4

前言

算法很重要，但是一般情况下做移动开发并不经常用到，所以很多同学早就将算法打了个大礼包送还给了老师了，况且很多同学并没有学习过算法。这个系列就让对算法头疼的同学能快速的掌握基本的算法。过年放假阶段玩了会游戏NBA2K17的生涯模式，没有比赛的日子也都是训练，而且这些训练都是自发的，没有人逼你，从早上练到晚上，属性也不涨，但是如果日积月累，不训练和训练的人的属性值就会产生较大差距。这个突然让我意识到了现实世界，要想成为一个球星（技术大牛）那就需要日积月累的刻意训练，索性放下游戏，接着写文章吧。

1.算法的效率

虽然计算机能快速的完成运算处理，但实际上，它也需要根据输入数据的大小和算法效率来消耗一定的处理器资源。要想编写出能高效运行的程序，我们就需要考虑到算法的效率。
算法的效率主要由以下两个复杂度来评估：
时间复杂度：评估执行程序所需的时间。可以估算出程序对处理器的使用程度。
空间复杂度：评估执行程序所需的存储空间。可以估算出程序对计算机内存的使用程度。

概述

单例模式（Singleton Pattern）是最基础的设计模式，也是Java面试常考问题之一。单例模式提供了一种创建对象实例的方式。单例类只有一个实例，并为所有其他类提供一个获取实例的方法。

为什么要用单例模式

优点

• 开销低：内存中只有一个对象实例，降低了系统在创建和销毁对象实例时产生的内存消耗。
• 效率高：只创建一次对象实例，GC 次数减少，提高 GC 工作效率

使用场景

• 生成 UUID(Universally Unique Identifier)。
• 计数器使用单例缓存，可以不必每次刷新都在数据库里加一次。
• 需要控制实例数量，降低系统开销的场景。

单例模式的实现方式

单例模式的实现模式大致分为以下两类：

• 懒汉式：全局单例实例在类加载时构建
• 饿汉式：全局单例实例在被第一次调用时构建

概述

概念

外观模式（Facade Pattern）隐藏了系统的复杂性，并向客户端提供了一个可以访问系统的接口。这种类型的设计模式属于结构性模式。为子系统中的一组接口提供了一个能够统一访问的高层接口，这个接口使得子系统更容易被访问或者使用。

主要组成部分

1. 门面：外观模式的核心。客户端调用门面角色，它熟悉子系统的功能。门面内部根据客户端需求封装了子系统功能的组合。
2. 子系统：实现子系统的功能。对客户端和门面都隐藏了其内部细节。子系统内部可以有系统内的相互交互，也可以提供外界调用的接口。
3. 客户端：通过调用门面来完成要实现的功能。

为什么要用外观模式

优点

1. 松耦合：解除客户端和子系统之间的耦合，让子系统内部的模块功能更易于扩展和维护。
2. 易用性：客户端不必知道子系统复杂的内部实现方式，只需跟门面交互即可。
3. 内外分离：子系统中，有些方法是对系统外的，有些方法是对系统内部相互交互使用的。子系统把暴露给外部的功能集中到门面中，从而实现客户端在不知道子系统内部细节前提下的调用

原文作者：零壹技术栈
文章转载自：https://juejin.im/post/5b48b0d7e51d4519962ea383

前言

数字签名、信息加密 是前后端开发都经常需要使用到的技术，应用场景包括了用户登入、交易、信息通讯、oauth 等等，不同的应用场景也会需要使用到不同的签名加密算法，或者需要搭配不一样的 签名加密算法 来达到业务目标。这里简单的给大家介绍几种常见的签名加密算法和一些典型场景下的应用。

正文

1. 数字签名

数字签名，简单来说就是通过提供 可鉴别 的 数字信息 验证 自身身份 的一种方式。一套 数字签名 通常定义两种 互补 的运算，一个用于 签名，另一个用于 验证。分别由 发送者 持有能够 代表自己身份 的 私钥 (私钥不可泄露),由 接受者 持有与私钥对应的 公钥 ，能够在 接受 到来自发送者信息时用于 验证 其身份。

注意：图中 加密过程 有别于 公钥加密，更多 介绍戳这里。签名 最根本的用途是要能够唯一 证明发送方的身份，防止 中间人攻击、CSRF 跨域身份伪造。基于这一点在诸如 设备认证、用户认证、第三方认证 等认证体系中都会使用到 签名算法 (彼此的实现方式可能会有差异)。

公司一（数据通信项目组）

一面

1. synchronized修饰方法和代码块有什么区别？
2. CAS单点登录的原理？
3. CAS锁有了解吗？
   即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数：

• 需要读写的内存值 V
• 进行比较的值 A
• 拟写入的新值 B
  当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

4. 并发锁有了解吗？
5. 手写一个单例模式
6. 单向链表了解吗？如何判断两个无环单向链表是否相交？

• 方法1：先循环链表1，将每个节点的地址进行hash计算存入哈希表，然后计算链表2的每个节点的地址的hash值，若与hash表中对应位置有值，则相交，否则不相交。
• 方法2：见链表1与2进行首尾相连，判断新链表是否有环，若没有，则不相交，若有环，则是相交的。
• 方法3：先计算两个链表的长度L1、L2，若L1 > L2，则先将链表1移动（L1 - L2）个节点，等到链表1和链表2剩下的长度一样的时候，一起向后移动，依次判断当前链表的节点是否相等，若相等，则相交，若到队尾还没有相等的，则不相交

消息丢失解决方案

前言

书接上回，消息被重复消费会产生数据库数据重复插入的问题。同样，消息丢失也是消息在传输过程中可能出现的问题之一，一旦消息在传输过程中发生丢失，就会造成数据库中的数据出错。

在实际应用中，如果使用MQ来传递核心业务消息，如计费、扣费等消息，一旦消息丢失，就可能造成重大经济损失，因此此时必须要确保消息在传递过程中不会丢失。

怎么保证消息不丢失？

消息丢失问题可能出现在生产者、MQ、消费者三个环节中的任意一个，接下来分别从这三个环节介绍一下 RabbitMQ 和 Kafka 的消息丢失解决方案

概述

RabbitMQ 是由 Erlang 语言开发的，基于AMQP（Advanced Message Queue 高级消息队列协议）协议实现的消息队列。

Erlang 是一种通用的并发程序设计语言，它由乔·阿姆斯特朗（Joe Armstrong）在瑞典电信设备制造商爱立信所辖的计算机科学研究室开发，目的是创造一种可以应付大规模并发活动的程序设计语言和运行环境。

特性

• 响应速度是微秒级，非常快。
• 轻量级，易于在操作系统和云中部署运行。
• 有强大的管理插件，方便用户在浏览器中管理RabbitMQ。
• 不支持分布式，但可以以镜像集群模式保证高可用。
• 开发社区非常活跃，文档完善，易于后期维护。

快速入门

入门程序工作模式

生产者发送消息到消息队列中，消费者从队列中获取消息。

今天在开发中使用Optional类避免NPE时遇到一个问题。

使用Optional集合调用isPresent()方法判断集合中是否有值存在，有返回其中的值，否则返回null

1
2
3
4
5
6
7

public Person getPersonById(String id){
       Optional<Person> optional = personRepository.findById(id);
       if (optional.isPresent()){
           return optional.get();
       }
       return null;
   }

问题来了，这时Idea出现黄色警告：Can be replaced with single expression in functional style. 可以被函数式表达式替换，于是我用idea自动修正，代码变成了：

前言

在实际生产环境下，消息被消费者重复消费是经常遇到问题之一。如何避免消息被重复消费，是消息队列领域的基本问题，也是在设计系统架构时必须考虑的问题。

RabbitMQ、RocketMQ、Kafka，各种消息中间件都有可能出现消息重复消费的问题，需要开发者来保证消息不被重复消费。

怎么保证消息不被重复消费？（以Kafka为例）

生产者在向Kafka写数据时，每条消息会有一个offset，表示消息写入顺序的序号。当消费者消费后，每隔一段时间会把自己已消费消息的offset通过Zookeeper提交给Kafka，告知Kafka自己offset的位置。这样一来，如果消费者重启，则会从Kafka记录的offset之后的数据开始消费，从而避免重复消费。

但是，可能出现一种意外情况。由于消费者提交offset是定期的，当消费者处理了某些消息，但还未来及提交offset时，此时如果重启消费者，则会出现消息的重复消费。

在实际生产中，引入消息队列技术固然会带来好处，比如降低系统耦合、异步提高响应速度、削平高峰期压力等。然而，任何技术都是一把双刃剑，引入消息队列的同时就要承担一定的风险：系统引入的外部依赖越多，越容易出问题。一旦消息中间件宕机，就会导致整个系统无法使用。因此，保证消息队列的高可用性非常重要。

怎么保证MQ的高可用？

RabbitMQ的高可用模式

RabbitMQ保证高可用有三种模式：单机模式，普通集群模式，镜像集群模式

• 单机模式

  测试环境下供开发者使用，不适用生产环境

• 普通集群模式

  在集群环境下部署多个MQ，但创建的消息队列（queue）会集中置于一个MQ实例中，其他每个实例同步该消息队列的元数据（可以理解为配置文件，但不是消息本身）。当消费者需要拉取消息时，如果并没有连接到消息队列所在实例，那么该实例会到消息队列所在实例上拉取消息。

  
  阅读全文 »