confirm

//重写alert window.alert = function(name){ var iframe = document.createElement("IFRAME"); iframe.style.display="none"; iframe.setAttribute("src", 'data:text/plain,'); document.documentElement.appendChild(iframe); window.frames[0].window.alert(name); iframe.parentNode.removeChild(iframe); } //重写confirm 不显示ip地址 var wConfirm = window.confirm; window.confirm = function (message) { try { var iframe = document.createElement("IFRAME"); iframe.style.display = "none"; iframe.setAttribute("src", 'data:text/plain,'); document.documentElement.appendChild(iframe); var alertFrame = window.frames[0]; var

注意需要引用到layer.js文件。整个样式是这样的 function DeleteData ($id) { var delete_id = $id ; layer. confirm ( ' ' , { btn : [ ' ' , ' ' ] } , function () { $.ajax({ type : 'post' , url : "?s=/Achievements/SetPerformStandard/DeleteDataById" , data :{ delete_id :delete_id } , success : function () { location . reload () ; } , error : function () { alert ( 'delete none0' ) ; } }) ; } , function () { }) ; } 文章来源: tp5 删除数据框提示 layer.confirm

这个是肯定的，用 MQ 有个基本原则，就是 数据不能多一条，也不能少一条 ，不能多，就是前面说的 重复消费和幂等性问题 。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。 如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这个 MQ 传递过程中 绝对不会把计费消息给弄丢 。 面试题剖析 数据的丢失问题，可能出现在生产者、MQ、消费者中，咱们从 RabbitMQ 和 Kafka 分别来分析一下吧。 RabbitMQ 生产者弄丢了数据 生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。 此时可以选择用 RabbitMQ 提供的事务功能，就是生产者 发送数据之前 开启 RabbitMQ 事务 channel.txSelect ，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务 channel.txRollback ，然后重试发送消息；如果收到了消息，那么可以提交事务 channel.txCommit 。 // 开启事务 channel.txSelect try { // 这里发送消息 } catch (Exception e) { channel.txRollback // 这里再次重发这条消息 } // 提交事务 channel

问题 textarea组件加上show-confirm-bar=“false”，完成按钮不隐藏 方法 show-confirm-bar = "{{false}}" 文章来源: https://blog.csdn.net/weixin_41471128/article/details/90412734

明天再整理 分布式事务解决方案之TCC 4.1.什么是TCC事务 TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。 分支事务失败的情况： TCC分为三个阶段： 1. Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。 2. Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

提示是否进行链接跳转 知识点： onclick="return confirm('确认跳转么？')" 代码： <a onclick="return confirm('确认禁用该粉丝么？')" href="{php echo $this->createWebUrl($filename, array('op' => 'disable', 'openid' => $fan['openid']))}" class="btn btn-primary">禁用</a> 来源： https://www.cnblogs.com/GetcharZp/p/11763005.html

overview→Totals 所有队列的阻塞情况 Ready：待消费的消息总数 Unacked：待应答的消息总数 Total：总数 Ready+Unacked Publish：producter pub消息的速率。 Publisher confirm：broker确认pub消息的速率。 Deliver(manual ack)：customer手动确认的速率。 Deliver( auto ack)：customer自动确认的速率。 Consumer ack：customer正在确认的速率。 Redelivered：正在传递'redelivered'标志集的消息的速率。 Get (manual ack)：响应basic.get而要求确认的消息的传输速率。 Get (auto ack)：响应于basic.get而发送不需要确认的消息的速率。 Return：将basic.return发送给producter的速率。 Disk read：queue从磁盘读取消息的速率。 Disk write：queue从磁盘写入消息的速率。 整体角色的个数 Connections：client的tcp连接的总数。 Channels：通道的总数。 Exchange：交换器的总数。 Queues：队列的总数。 Consumers：消费者的总数。 Overview→Nodes broker的属性 Name

1、2PC协议 　　2PC 是二阶段提交（Two-phase Commit）的缩写，顾名思义，这个协议分两阶段完成。第一个阶段是准备阶段，第二个阶段是提交阶段，准备阶段和提交阶段都是由事务管理器（协调者）发起的，协调的对象是资源管理器（参与者）。二阶段提交协议的概念来自 X/Open 组织提出的分布式事务的规范 XA 协议，协议主要定义了（全局）事务管理器和（局部）资源管理器之间的接口。XA 接口是双向的系统接口，在事务管理器以及一个或多个资源管理器之间形成通信桥梁。Java 平台上的事务规范 JTA（Java Transaction API）提供了对 XA 事务的支持，它要求所有需要被分布式事务管理的资源（由不同厂商实现）都必须实现规定接口（XAResource 中的 prepare、commit 和 rollback 等）。 　　两阶段如下： ① 准备阶段 　　协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，参与者会写 redo 和 undo 日志，然后锁定资源，执行操作，但是并不提交。 ② 提交阶段 　　如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者明确返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令

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