「java异步处理事务」java异步线程
本篇文章给大家谈谈java异步处理事务，以及java异步线程对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、java异步处理数据时时数据还没存到库里
- 2、java中异步处理和同步处理分别是什么意思？
- 3、java中异步处理和同步处理分别是什么意思
- 4、java 异步调用方法
- 5、如何在Spring事务提交后进行异步操作
- 6、Java分布式系统处理分布式事务有哪些经典解决方
java异步处理数据时时数据还没存到库里
这是正常的，异步处理都是这有问题。特别是数据库开启事务的时候，上一个线程还没有提交的话，其他事务是看不到数据的。解决的办法就是要么采用同步的机制，在同一个线程中处理数据，自然就不会存在这种问题。如果一定要用异步的话，可以加入等待机制，就是判断数据是否入库，没有点话就等待一会儿，然后在判断，直到入库才进行后续的处理
java中异步处理和同步处理分别是什么意思？
同步:发送一个请求,等待返回,然后再发送下一个请求
异步:发送一个请求,不等待返回,随时可以再发送下一个请求
同步可以避免出现死锁，读脏数据的发生，一般共享某一资源的时候用，如果每个人都有修改权限，同时修改一个文件，有可能使一个人读取另一个人已经删除的内容，就会出错，同步就会按顺序来修改。
异步则是可以提高效率了，现在cpu都是双核，四核，异步处理的话可以同时做多项工作，当然必须保证是可以并发处理的。
这些都是对的。
同步和异步最大的区别就在于。一个需要等待，一个不需要等待。
比如广播，就是一个异步例子。发起者不关心接收者的状态。不需要等待接收者的返回信息
电话，就是一个同步例子。发起者需要等待接收者，接通电话后，通信才开始。需要等待接收者的返回信息
java中异步处理和同步处理分别是什么意思
举个例子：A和B一起从某点出发到终点。
同步就是只能A走完某一段然后停下，让B开始走一段再停下，再让A走。如此往复。简单理解就是，必须是一段程序执行完后才能执行后面的程序。
异步就是，同一时间可能A和B同时都在往终点赶，此时不存在先后顺序，就是说，两个程序可以同时执行，称为异步。
java 异步调用方法
asynchronous call（异步调用）
一个可以无需等待被调用函数的返回值就让操作继续进行的方法
中文名
异步调用
外文名
asynchronous call
领域
函数
杰作
线程
。
。
快速
导航
实战用法异步调用使用方法
举例
异步调用就是你 喊 你朋友吃饭 ，你朋友说知道了 ，待会忙完去找你 ，你就去做别的了。
同步调用就是你 喊 你朋友吃饭 ，你朋友在忙 ，你就一直在那等，等你朋友忙完了 ，你们一起去。
实战用法
操作系统发展到今天已经十分精巧，线程就是其中一个杰作。操作系统把 CPU 处理时间划分成许多短暂时间片，在时间 T1 执行一个线程的指令，到时间 T2又执行下一线程的指令，各线程轮流执行，结果好象是所有线程在并肩前进。这样，编程时可以创建多个线程，在同一期间执行，各线程可以“并行”完成不同的任务。
在单线程方式下，计算机是一台严格意义上的冯·诺依曼式机器，一段代码调用另一段代码时，只能采用同步调用，必须等待这段代码执行完返回结果后，调用方才能继续往下执行。有了多线程的支持，可以采用异步调用，调用方和被调方可以属于两个不同的线程，调用方启动被调方线程后，不等对方返回结果就继续执行后续代码。被调方执行完毕后，通过某种手段通知调用方：结果已经出来，请酌情处理。
如何在Spring事务提交后进行异步操作
实现方案
使用TransactionSynchronizationManager在事务提交之后操作
public void insert(TechBook techBook){
bookMapper.insert(techBook);
// send after tx commit but is async
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
System.out.println("send email after transaction commit...");
}
}
);
ThreadLocalRandom random = ThreadLocalRandom.current();
if(random.nextInt() % 2 ==0){
throw new RuntimeException("test email transaction");
}
System.out.println("service end");
}
该方法就可以实现在事务提交之后进行操作
操作异步化
使用mq或线程池来进行异步，比如使用线程池：
private final ExecutorService executorService = Executors.newFixedThreadPool(5);
public void insert(TechBook techBook){
bookMapper.insert(techBook);
// send after tx commit but is async
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
executorService.submit(new Runnable() {
@Override
public void run() {
System.out.println("send email after transaction commit...");
try {
Thread.sleep(10*1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("complete send email after transaction commit...");
}
});
}
}
);
// async work but tx not work, execute even when tx is rollback
// asyncService.executeAfterTxComplete();
ThreadLocalRandom random = ThreadLocalRandom.current();
if(random.nextInt() % 2 ==0){
throw new RuntimeException("test email transaction");
}
System.out.println("service end");
}
Java分布式系统处理分布式事务有哪些经典解决方
当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：
1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。
2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。
于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。 通常，我们会通过两种手段来扩展我们的数据服务：
1）数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。
2）数据镜像：让所有的服务器都有相同的数据，提供相当的服务。
对于第一种情况，我们无法解决数据丢失的问题，单台服务器出问题时，会有部分数据丢失。所以，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储（一般工业界认为比较安全的备份数应该是3份，如：Hadoop和Dynamo）。 但是，加入更多的机器，会让我们的数据服务变得很复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性。这个是一个很难的问题。 让我们用最经典的Use Case：“A帐号向B帐号汇钱”来说明一下，熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作：
从A帐号中把余额读出来。
对A帐号做减法操作。
把结果写回A帐号中。
从B帐号中把余额读出来。
对B帐号做加法操作。
把结果写回B帐号中。
为了数据的一致性，这6件事，要么都成功做完，要么都不成功，而且这个操作的过程中，对A、B帐号的其它访问必需锁死，所谓锁死就是要排除其它的读写操作，不然会有脏数据的问题，这就是事务。那么，我们在加入了更多的机器后，这个事情会变得复杂起来：
1）在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。这在跨机器的情况下，就变得比较复杂了。
2）在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作（要汇给B和C），这两个操作发生在不同的两台服务器上怎么办？也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突？
同时，我们还要考虑性能的因素，如果不考虑性能的话，事务得到保证并不困难，系统慢一点就行了。除了考虑性能外，我们还要考虑可用性，也就是说，一台机器没了，数据不丢失，服务可由别的机器继续提供。 于是，我们需要重点考虑下面的这么几个情况：
1）容灾：数据不丢、节点的Failover
2）数据的一致性：事务处理
3）性能：吞吐量 、 响应时间
前面说过，要解决数据不丢，只能通过数据冗余的方法，就算是数据分区，每个区也需要进行数据冗余处理。这就是数据副本：当出现某个节点的数据丢失时可以从副本读到，数据副本是分布式系统解决数据丢失异常的唯一手段。所以，在这篇文章中，简单起见，我们只讨论在数据冗余情况下考虑数据的一致性和性能的问题。简单说来：
1）要想让数据有高可用性，就得写多份数据。
2）写多份的问题会导致数据一致性的问题。
3）数据一致性的问题又会引发性能问题
这就是软件开发，按下了葫芦起了瓢。
一致性模型
说起数据一致性来说，简单说有三种类型（当然，如果细分的话，还有很多一致性模型，如：顺序一致性，FIFO一致性，会话一致性，单读一致性，单写一致性，但为了本文的简单易读，我只说下面三种）：
1）Weak 弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系，VOIP这样的系统，或是百度搜索引擎（呵呵）。
2）Eventually 最终一致性：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件、Amazon S3，Google搜索引擎这样的系统。
3）Strong 强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。
从这三种一致型的模型上来说，我们可以看到，Weak和Eventually一般来说是异步冗余的，而Strong一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。 好，让我们由浅入深，一步一步地来看有哪些技术：
Master-Slave
首先是Master-Slave结构，对于这种加构，Slave一般是Master的备份。在这样的系统中，一般是如下设计的：
1）读写请求都由Master负责。
2）写请求写到Master上后，由Master同步到Slave上。
从Master同步到Slave上，你可以使用异步，也可以使用同步，可以使用Master来push，也可以使用Slave来pull。 通常来说是Slave来周期性的pull，所以，是最终一致性。这个设计的问题是，如果Master在pull周期内垮掉了，那么会导致这个时间片内的数据丢失。如果你不想让数据丢掉，Slave只能成为Read-Only的方式等Master恢复。
当然，如果你可以容忍数据丢掉的话，你可以马上让Slave代替Master工作（对于只负责计算的节点来说，没有数据一致性和数据丢失的问题，Master-Slave的方式就可以解决单点问题了） 当然，Master Slave也可以是强一致性的， 比如：当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后返回成功，整个过程是同步的，如果写Slave失败了，那么两种方法，一种是标记Slave不可用报错并继续服务（等Slave恢复后同步Master的数据，可以有多个Slave，这样少一个，还有备份，就像前面说的写三份那样），另一种是回滚自己并返回写失败。（注：一般不先写Slave，因为如果写Master自己失败后，还要回滚Slave，此时如果回滚Slave失败，就得手工订正数据了）你可以看到，如果Master-Slave需要做成强一致性有多复杂。
Master-Master
Master-Master，又叫Multi-master，是指一个系统存在两个或多个Master，每个Master都提供read-write服务。这个模型是Master-Slave的加强版，数据间同步一般是通过Master间的异步完成，所以是最终一致性。 Master-Master的好处是，一台Master挂了，别的Master可以正常做读写服务，他和Master-Slave一样，当数据没有被复制到别的Master上时，数据会丢失。很多数据库都支持Master-Master的Replication的机制。
另外，如果多个Master对同一个数据进行修改的时候，这个模型的恶梦就出现了——对数据间的冲突合并，这并不是一件容易的事情。看看Dynamo的Vector Clock的设计（记录数据的版本号和修改者）就知道这个事并不那么简单，而且Dynamo对数据冲突这个事是交给用户自己搞的。就像我们的SVN源码冲突一样，对于同一行代码的冲突，只能交给开发者自己来处理。（在本文后后面会讨论一下Dynamo的Vector Clock）
Two/Three Phase Commit
这个协议的缩写又叫2PC，中文叫两阶段提交。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
关于java异步处理事务和java异步线程的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。