confirm

本文是继上篇博客的补充，不清楚原文的同学请看这里 关于新型冠状病毒肺炎疫情追踪的可视化数据的采集、处理 最终效果图 有些细心的小伙伴在看了上篇博客后告诉我，尽管抓取的数据确实不少，但还是遗漏了一个十分重要的数据——每日疫情数据的变化趋势 首先，感谢你们的好心提醒以及对我的鼓励！感谢你们能够赏脸看我的文章！ 其实抓取这些数据和上篇博客提到的方法是一样的，看过的小伙伴们就当是重温一遍叭 数据准备：要抓取数据，自然需要找一个具有这样数据的数据源，那就找呗 于是发现了网易新闻提供了一个这样的数据源 url：https://news.163.com/special/epidemic/ 开干！ 数据采集：和上篇一样，使用谷歌浏览器自带的开发者工具进行数据包抓取 采集过程：和上篇一样，打开开发者工具的捕获按钮后，F5刷新查看数据包，搜索对应的数据 如图，我直接搜索第一个数据 93（但是要注意一下“新增确诊人数”，因为你观察一下“累计确诊人数”中的数据后，可以得知“新增确诊人数”是相邻两个“累计确诊人数”的差，如果直接搜“新增确诊人数”的话，可能无法搜索到我们要找的数据包，原因是“新增确诊人数”的数据完全是可以通过计算得出的） 但是在排查这些数据包发现，这些数据包太多了，很难找到。没关系，我们换一个数据，搜索“累计确诊人数”里的数据看看，以1975为例，发现只有一个搜索结果，如图

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务 一、业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 二、进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring

今日目标 1.修改用户,删除用户 2.推送代码到码云 3.权限列表 4.角色列表 5.分配角色 1.修改用户信息 A.为用户列表中的修改按钮绑定点击事件 B.在页面中添加修改用户对话框，并修改对话框的属性 C.根据id查询需要修改的用户数据 //展示编辑用户的对话框 async showEditDialog(id) { //发送请求根据id获取用户信息 const { data: res } = await this.$http.get('users/' + id) //判断如果添加失败，就做提示 if (res.meta.status !== 200) return this.$message.error('获取用户信息失败') //将获取到的数据保存到数据editForm中 this.editForm = res.data //显示弹出窗 this.editDialogVisible = true } D.在弹出窗中添加修改用户信息的表单并做响应的数据绑定以及数据验证 <!-- 对话框主体区域 --> <el-form :model="editForm" :rules="editFormRules" ref="editFormRef" label-width="70px"> <el-form-item label="用户名"> <el-input v-model=

Friend直接流程建立都是通过上层传输曾的控制PDU进行交互。控制消息大部分都为不分段消息，所以这一章我们以下层传输层的为分段消息作为PDU格式的总体示意图。 1. Friendship相关Control PDU 1.1. Friend Poll 由LPN发起，请求Friend发送LPN睡眠期间为LPN存储的消息。 Opcode=0x01，对应的Parameters如下所示： Field Size(bits) Notes Padding 7 0b0000000，固定值 FSN 1 Friend Sequence Number TTL域设置为0。 消息使用 friendship security credentials加密。 1.2. Friend Update Friend通知LPN安全参数已经改变，或者当前消息队列为空。 Opcode=0x02，对应的Parameters如下所示： Field Size(octets) Notes Flags 1 第0个bit表示当前的Key Refresh阶段 第1个bit表示当前的IV Update状态 第2-7位RFU IV Index 4 Friend节点当前的IV Index MD 1 MD=0：表明Friend Queue为空 MD=1：表明Friend Queue非空 Field Notes Key Refresh Flag 0

一、RabbitMQ 1）生产者弄丢了数据 　　生产者将数据发送到rabbitmq的时候，可能因为网络问题导致数据就在半路给搞丢了。 1.可以选择用rabbitmq提供的事务功能，在生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，开始rabbitmq事务机制，基本上吞吐量会下来，因为太耗性能。 2.（推荐）可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。 　　 　　事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息