科技新闻

3 月，跳不动了？>>> 前言 NAT：网络地址转换（Network Address Translation），也叫做网络掩蔽或者IP掩蔽（IP masquerading），是一种在IP封包通过路由器或防火墙时重写來源IP地址或目的IP地址的技术。 简单来说在数据传输中，经过7层网络结构时，为了实现三次握手，就需要在发送数据的时候告诉目的地你的位置，以便对方可以回复，但是在数据报中只有起点域和目的域，不可能所有的终端都是点对点连接的，这时候就需要一个中转站来传递消息数据，这里只讨论软件来实现 nat，路由器的由于基本不会直接操作，就没查资料了。 iptables 实现 NAT iptables 作用的 5 条规则链中，有两条是 PREROUTING、POSTROUTING，分别代表的是路由前和路由后，iptables 就是实现 nat 的一种方式。 检查系统是否开启了 ip 转发功能： cat /etc/sysctl.conf| grep 'net.ipv4.ip_forward = 0' 开启转发功能： sed -i 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf 在 iptables 中添加 NAT 转换规则： iptables -t nat -I PREROUTING -p tcp

Kafka kafka是什么？kafka仅仅是属于消息 中间件吗？ kafka在设计之初的时候 开发人员们在除了消息中间件以外，还想吧kafka设计为一个能够存储数据的系统，有点像 常见的非关系型数据库，比如说NoSql等。除此之外 还希望kafka能支持持续变化，不断增长的数据流, 可以发布 和订阅数据流，还可以对于这些数据进行保存 也就是说kafka的本质 是一个数据存储平台，流平台 ， 只是他在做消息发布，消息消费的时候我们可以把他当做 消息中间件来用。 而且kafka在设计之初就是采用分布式架构设计的， 基于集群的方式工作，且可以自由伸缩，所以 kafka构建集群 非常简单 基本概念： Broker : 和AMQP里协议的概念一样， 就是消息中间件所在的服务器 Topic(主题) : 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息 分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消 费数据而不必关心数据存于何处） Partition(分区) : Partition是物理上的概念，体现在磁盘上面，每个Topic包含一个或多个Partition. Producer : 负责发布消息到Kafka broker Consumer : 消息消费者，向Kafka

3 月，跳不动了？>>> 案例1，缓存和DB的数据不同步（不一致） 后台系统CRM更新产品数据到DB，产品系统收到异步消息通知后，更新最新数据到缓存。这是一个最常见的缓存应用场景，我相信很多团队都是这样用的。在这个Case里容易出现的问题在于，如果产品系统收到消息后服务挂掉了，缓存没有正常更新，就出现缓存与DB的数据不同步，前端系统一直不能读到最新数据，导致业务异常。 解决方案： 1. mq消费端创建个本地消息表，对于消费失败的消息进行重试 2. 系统要有缓存更新的报警机制，方便更新失败或者重试超时后，可以人工介入进行补偿。 案例2， 同时被两次请求update时，db数据被错误覆盖 CRM系统更新了某个用户的Profile, 保存更新数据库后，通过MQ通知用户系统更新缓存，由于是异步更新延迟，在缓存更新前，用户系统收到前端的请求，读取了当前缓存里的用户数据，做了修改，并更新到DB中。出现的结果就是数据库里的CRM的更新被错误覆盖。 解决方案：缓存里的数据有一个标志位可以作为更新数据库数据的依据（Update_time or Version）, 如果缓存里数据时间与数据库时间不能匹配，意味着另外一个服务更新了该数据，那么就先从DB里读取最新数据版本，然后在新版本上提交数据。 案例3， 并发查询缓存中同一数据，如果缓存没命中，导致DB瞬时被打爆 做促销活动的时候

3 月，跳不动了？>>> 一、先扔一张图 说明: 本文涵盖了关于RabbitMQ很多方面的知识点, 如: 消息发送确认机制 消费确认机制 消息的重新投递 消费幂等性, 等等 这些都是围绕上面那张整体流程图展开的, 所以有必要先贴出来, 见图知意 二、实现思路 简略介绍163邮箱授权码的获取 编写发送邮件工具类 编写RabbitMQ配置文件 生产者发起调用 消费者发送邮件 定时任务定时拉取投递失败的消息, 重新投递 各种异常情况的测试验证 拓展: 使用动态代理实现消费端幂等性验证和消息确认(ack) 三、项目介绍 springboot版本2.1.5.RELEASE, 旧版本可能有些配置属性不能使用, 需要以代码形式进行配置 RabbitMQ版本3.7.15 MailUtil: 发送邮件工具类 RabbitConfig: rabbitmq相关配置 TestServiceImpl: 生产者, 发送消息 MailConsumer: 消费者, 消费消息, 发送邮件 ResendMsg: 定时任务, 重新投递发送失败的消息 说明: 上面是核心代码, MsgLogService mapper xml等均未贴出, 完整代码可以参考GitHub上的源码，地址在文末。 四、代码实现 1、163邮箱授权码的获取, 如图: 该授权码就是配置文件spring.mail.password需要的密码 2、pom

FreeSWITCH的命令不仅可以在控制台使用，也可以在各种嵌入式脚本、Event Socke或者HTTP RPC上使用，所有命令都遵循一个抽象的接口，这些命令称为API Commands。 查看所有API命令的帮助信息 help show api 常用的API命令 fsctl FreeSWITCH控制消息 例如： 1. fsctl shutdown restart 重启FreeSWITCH 2. fsctl sps <number> 临时修改swithch.conf文件中设置的sessions-per-second（每秒并发通话数） 3. fsctl max_sessions <number> 临时修改switch.xml文件中设置的max_session控制最大并发数 status 查看当前FreeSWITCH运行的基本信息 show 输出多种（模块）状态报告。 例如： 1. show calls 2. show channels 3. show api global_getvar 获取全局变量的值。如果没有提供参数，则返回所有全局变量的值。 用法：global_getvar <varname> 例如：global_getvar local_ip_v4 eval 求值 用法：eval [uuid:<uuid> ]<expression> 例如：eval $${local_ip

一：初识kafka 　　对于大型的分布式系统来说，消息中间件可以说是必不可少的，它的核心功能有 解耦 、 异步 、 削峰， 之前说的 RabbitMQ 就是其中一种，而kafka则是消息中间件的又一利器。 首先看一下官网（ http://kafka.apache.org/intro ）的介绍：Apache Kafka is a distributed streaming platform。 流平台具有三个关键功能： 发布和订阅记录流，类似于消息队列或企业消息传递系统。 以容错的持久方式存储记录流。 处理记录流。 Kafka是一款基于发布与订阅的消息系统。 二：kafka核心概念 1：主题和分区日志： 　　kafka中消息订阅和发布都是基于某个主题（topic）的，一个主题中又可以被分为很多分区（partition），kafka无法保证整个主题内消息的顺序但是可以保证分区消息的顺序性。 当消息被写入时，如果键为null，默认的分区器会使用轮询算法均衡的把消息写入到各个分区上，如果键不为null，默认分区器会根据键的散列值映射到特定的分区上，同一个键的消息一定是会被写入到同一个分区上的。因此创建主题时就确认好分区，不要后在主题下新增分区。 2：生产者 　　生产者一般是将一个消息发布到一个自己选择的主题上，在某些情况下，生产者可以把消息发布到指定的分区，这是通过消息键和分区器实现的。

消息循环 1 BOOL GetMessage( 2 LPMSG lpMsg, ==》指向一个消息结构体 3 HWND hWnd, ==》 通常设置为NULL 4 UINT wMsgFilterMin, ==》 获取消息的最小值，通常设置为0 5 UINT wMsgFilterMax ==》 获取消息的最大值 6 ); GetMessage 接收到除 WM_QUIT 外的消息均返回非零值。实例： 1 MSG msg; 2 while (GetMessage(&msg,NULL,0,0)) 3 { 4 TranslateMessage(&msg); 5 DispatchMessage(&msg); 6 } 来源： https://www.cnblogs.com/thismelongaotian/p/12560506.html

3 月，跳不动了？>>> WebSocket的生命周期 WebSocket的端点，以事件的角度看，有四个生命周期事件： 打开事件：此事件发生在端点上建立连接时并且在任何其他事件发生之前； 消息事件：此事件在接收WebSocket对话中另一端发送的消息。它可以发生在WebSocket端点接收了打开事件之后并且在接收关闭事件关闭之前的任何时刻发生； 错误事件：此事件在WebSocket连接或端点发生错误时发生； 关闭事件：此事件在WebSocket连接或者端点发生错误时发生； 以注解来声明这的话，可以用@OnOpen、@OnMessage、@OnError和@OnClose这四个注解。 以一个例子来体现WebSocket的生命周期： 点击打开连接按钮，与端点进行连接，这个时候会执行@OnOpen修饰的函数。 点击发送消息，向端点发送文本框中的内容，这个时候会执行@OnMessage修饰的函数。 点击关闭客户端连接按钮，客户端终端与端点的连接，这个时候会调用@OnClick修饰的函数。 点击关闭服务端连接： 端点关闭连接，关闭时大多数会产生一个异常会执行由@OnError修饰的函数，具体代码如下： <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema

最近看了 @JavaGuide 发布的一篇 『面试官问我如何保证Kafka不丢失消息?我哭了！』 ，这篇文章承接这个主题，来聊聊如何保证 RocketMQ 不丢失消息。 0x00. 消息的发送流程 一条消息从生产到被消费，将会经历三个阶段： 生产阶段，Producer 新建消息，然后通过网络将消息投递给 MQ Broker 存储阶段，消息将会存储在 Broker 端磁盘中 消息阶段， Consumer 将会从 Broker 拉取消息 以上任一阶段都可能会丢失消息，我们只要找到这三个阶段丢失消息原因，采用合理的办法避免丢失，就可以彻底解决消息丢失的问题。 0x01. 生产阶段 生产者（Producer） 通过网络发送消息给 Broker，当 Broker 收到之后，将会返回确认响应信息给 Producer。所以生产者只要接收到返回的确认响应，就代表消息在生产阶段未丢失。 RocketMQ 发送消息示例代码如下： DefaultMQProducer mqProducer=new DefaultMQProducer("test"); // 设置 nameSpace 地址 mqProducer.setNamesrvAddr("namesrvAddr"); mqProducer.start(); Message msg = new Message("test_topic" /* Topic

MD5消息摘要算法 （ 英语： MD5 Message-Digest Algorithm），一种被广泛使用的密码散列函数，可以产生出一个128位（16字节）的散列值（hash value），用于确保信息传输完整一致。MD5由美国密码学家罗纳德·李维斯特（ Ronald Linn Rivest）设计，于1992年公开，用以取代MD4算法。这套算法的程序在 RFC 1321 中被加以规范。 将数据（如一段文字）运算变为另一固定长度值，是散列算法的基础原理。 1996年后被证实存在弱点，可以被加以破解，对于需要高度安全性的数据，专家一般建议改用其他算法，如SHA-2。2004年，证实MD5算法无法防止碰撞（collision），因此不适用于安全性认证，如SSL公开密钥认证或是数字签名等用途。2009年，中国科学院的谢涛和冯登国仅用了2 20.96 的碰撞算法复杂度，破解了MD5的碰撞抵抗，该攻击在普通计算机上运行只需要数秒钟。 　　MD5输入不定长度信息，输出固定长度128bits，一般的128位MD5散列会被表示为32位十六进制数，还有的表示为16位十六进制数，16位就是32位去掉前八位和后八位。 　　在Java中生成字符串的MD5值： 　　 public class MD5 { private static Logger logger = LoggerFactory