confirm

在实际系统中，在完成某些操作时会弹出对话框来提示，主要分为"警告消息框","确认消息框","提示消息对话"三种类型的对话框。 1.警告消息框（alert） 　　警告消息框提供了一个"确定"按钮让用户关闭该消息框，并且该消息框是模式对话框，也就是说用户必须先关闭该消息框然后才能继续进行操作。 2.确认消息框（confirm） 　　确认消息框向用户提示一个"是与否"问题，用户可以根据选择"确定"按钮和"取消"按钮。 3.提示消息对话（prompt） 　　提示消息框提供了一个文本字段，用户可以在此字段输入一个答案来响应您的提示。该消息框有一个"确定"按钮和一个"取消"按钮。选择"确认"会响应对应的提示信息，选择"取消"会关闭对话框。 selenium 提供switch_to_alert()方法定位到 alert/confirm/prompt对话框。使用 text/accept/dismiss/send_keys 进行操作，这里注意的是send_keys只能对prompt进行操作。 switch_to_alert() 　　#定位弹出对话 text() 　　 #获取对话框文本值 accept() #相当于点击"确认" dismiss() #相当于点击"取消" send_keys() # 输入值，这个alert和confirm没有输入对话框，所以这里就不能用了

webdriver中处理js所生成的alert、confirm以及prompt，采用switch_to_alert()方法定位到alert/confirm/prompt。然后使用text/accept/dismiss/send_keys进行操作 　　①text：返回alert/confirm/prompt中的文字信息 　　②accept：点击确认按钮 　　③dismiss：点击取消按钮 　　④send_keys：输入值，这个alert/confirm/prompt没有对话框就不能使用，否则会报错 eg：百度的设置页面，在设置完成后点击“保存设置”所弹的提示框 ======================================================= #!/usr/bin/python # -*- coding: utf-8 -*- __author__ = 'zuoanvip' from selenium import webdriver import time driver = webdriver.Firefox() driver.get('http://www.baidu.com') #打开搜索设置 driver.find_element_by_name('tj_setting').click() driver.find_element_by_id('SL

TCC和XA的区别和概述 TCC 主要限制 对业务有侵入性，需要提供了三个接口。 主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。如果从业务方还不是自己的公司的话那更是成本提高了（可能人家都不搭理你），原来只需要提供一个接口，现在需要改造成try、confirm、canel3个接口，开发成本高。 使用范围（业务层面的控制） 分布式架构，TCC是分布式事务，是最终一致性的，不会长期持有所有数据库资源的锁，原理上还是提交本地事务，所以不会存在长事务，这样就和本地事事务没有区别，性能很好。 第一阶段由发起方（发起所在的程序）发出try请求，第二阶段由事务管理器发起confirm／cancel请求，而且采用了异步实现。 概述和原理 原来一个接口就可以，现在要提供三个接口 try 数据就生效了，提交了事务 confirm 确定下数据，查询try的数据是否正确 cancle 回滚数据，把try的数据回滚掉 XA（很少使用了） 主要限制 必须要拿到所有数据源，而且数据源还要支持XA协议。 性能比较差，要把所有涉及到的数据都要锁定，是强一致性的，会产生长事务。 使用范围（资源管理方面的控制） 适用于单体架构 概述和与原理 XA协议是由X/Open组织提出的一个分布式事务处理规范，目前MySQL中只有InnoDB存储引擎支持XA协议。 其中有几个概念： AP 代表我们的应用程序

主要内容 1、消息如何保证100%的投递？ 2、幂等性概念 3、Confirm确认消息 4、Return返回消息 5、自定义消费者 消息100%的投递 消息如何保障100%的投递成功？ 什么是生产端的可靠性投递？ 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点（Broker）确认应答 完善的消息进行补偿机制 BAT/TMD互联网大厂的解决方案： 消息落库，对消息状态进行打标 消息的延迟投递，做二次确认，回调检查 幂等性概念 幂等性是什么？ 我们可以借鉴数据库的乐观锁机制 比如我们执行一条更新库存的SQL语句 Update t_repository set count = count -1,version = version + 1 where version = 1 Elasticsearch也是严格遵循幂等性概念，每次数据更新，version+1（博主博客前面有提到） 消费端-幂等性保障 在海量订单产生的业务高峰期，如何避免消息的重复消费问题？ 消费实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息 业界主流的幂等性操作 唯一ID+指纹码机制，利用数据库主键去重 利用Redis的原子性去实现 唯一ID+指纹码 机制 唯一ID+指纹码机制，利用数据库主键去重 Select count(1) from T_order

目标 1、消息如何保证100%的投递？ 2、幂等性概念 3、Confirm确认消息 4、Return返回消息 5、自定义消费者 消息100%的投递 消息如何保障100%的投递成功？ 什么是生产端的可靠性投递？ 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点（Broker）确认应答 完善的消息进行补偿机制 BAT/TMD互联网大厂的解决方案： 消息落库，对消息状态进行打标 消息的延迟投递，做二次确认，回调检查 幂等性概念 幂等性是什么？ 我们可以借鉴数据库的乐观锁机制 比如我们执行一条更新库存的SQL语句 Update t_repository set count = count -1,version = version + 1 where version = 1 Elasticsearch也是严格遵循幂等性概念，每次数据更新，version+1（博主博客前面有提到） 消费端-幂等性保障 在海量订单产生的业务高峰期，如何避免消息的重复消费问题？ 消费实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息 业界主流的幂等性操作 唯一ID+指纹码机制，利用数据库主键去重 利用Redis的原子性去实现 唯一ID+指纹码 机制 唯一ID+指纹码机制，利用数据库主键去重 Select count(1) from T_order

1. 分布式事务原理解析 1.1. TCC分布式事务 了解过TCC分布式事务的都知道它有三个阶段：try，confirm，cancel，但很多文章就只有原理图，和对原理图的解释，看一遍也留不下印象，这里用实际场景举个例子，说明TCC分布式事务原理 try阶段：假设我们又订单系统，它需要调用库存和积分系统，try阶段我们进行的是 预处理 ，比如下单1个商品，在try操作中，我们在库存表设置个冻结字段，表示冻结1个商品，商品的存量先不扣除，而积分表同样添加个预增加积分字段，添加个预积分比如10 confirm阶段： 我们为什么要经历try阶段？ ，为了尽可能的保证各个系统都是正常工作的，数据库，服务都没有挂掉，资源没有不足，则可以最大程度上保证confirm阶段能正确执行， confirm阶段也就是正式的扣除库存和增加积分 cancel阶段： 若try阶段执行错误 ，则会对前面已经执行的try阶段的系统执行cancel操作，也就是反向SQL回滚，冻结的商品-1，预积分-10。到这里有没有疑问？我首先想到的是 若confirm或cancel操作再执行失败怎么办 ？这里就要由TCC分布式事务框架保证了，它会 记录事务活动日志 ，再confirm或cancel失败后不断尝试调用confirm和cancel的逻辑，所以这里需要开发者自己保证，你的SQL是正确的 TCC分布式框架推荐