避免并发
在分布式环境中，如果存在并发问题，那么很难通过技术去解决，或者解决的代价很大，所以我们首先要想想是不是可以通过某些策略和业务设计来避免并发。比如通过合理的时间调度，避开共享资源的存取冲突。另外，在并行任务设计上可以通过适当的策略，保证任务与任务之间不存在共享资源，比如在以前博文中提到的例子，我们需要用多线程或分布式集群来计算一堆客户的相关统计值，由于客户的统计值是共享数据，因此会有并发潜在可能。但从业务上我们可以分析出客户与客户之间 数据是不共享的，因此可以设计一个规则来保证一个客户的计算工作和数据访问只会被一个线程或一台工作机完成，而不是把一个客户的计算工作分配给多个线程去 完成。这种规则很容易设计，例如可以采用hash算法。
时间戳
分布式环境中并发是没法保证时序的，无论是通过远程接口的同步调用或异步消息，因此很容易造成某些对时序性有要求的业务在高并发时产生错误。比如系统A需要把某个值的变更同步到系统B，由于通知的时序问题会导致一个过期的值覆盖了有效值。对于这个问题，常用的办法就是采用时间戳的方式，每次系统A发送变更给系统B的时候需要带上一个能标示时序的时间戳，系统B接到通知后会拿时间戳与存在的时间戳比较，只有当通知的时间戳大于存在的时间戳，才做更新。这种方式比较简单，但关键在于调用方一般要保证时间戳的时序有效性。
串行化
有的时候可以通过串行化可能产生并发问题操作，牺牲性能和扩展性，来满足对数据一致性的要求。比如分布式消息系统就没法保证消息的有序性，但可以通过变分布式消息系统为单一系统就可以保证消息的有序性了。另外，当接收方没法处理调用有序性，可以通过一个队列先把调用信息缓存起来，然后再串行地处理这些调用。
数据库
分布式环境中的共享资源不能通过Java里同步方法或加锁来保证线程安全，但数据库是分布式各服务器的共享点，可以通过数据库的高可靠一致性机制来满足需求。比如，可以通过唯一性索引来解决并发过程中重复数据的生产或重复任务的执行；另外有些更新计算操作也尽量通过sql来完成，因为在程序段计算好后再去更新就有可能发生脏复写问题，但通过一条sql来完成计算和更新就可以通过数据库的锁机制来保证update操作的一致性。
行锁
有的事务比较复杂，无法通过一条sql解决问题，并且有存在并发问题，这时就需要通过行锁来解决，一般行锁可以通过以下方式来实现：
对于Oracle数据库，可以采用select ... for update方式。这种方式会有潜在的危险，就是如果没有commit就会造成这行数据被锁住，其他有涉及到这行数据的任务都会被挂起，应该谨慎使用
在表里添加一个标示锁的字段，每次操作前，先通过update这个锁字段来完成类似竞争锁的操作，操作完成后在update锁字段复位，标示已归还锁。这种方式比较安全，不好的地方在于这些update锁字段的操作就是额外的性能消耗
统一触发途径
当一个数据可能会被多个触发点或多个业务涉及到，就有并发问题产生的隐患，因此可以通过前期架构和业务设计，尽量统一触发途径，触发途径少了一是减少并发的可能，也有利于对于并发问题的分析和判断。
如何保证高并发时线程安全？
对于商城一类系统中，单点登录、购物车、订单这些都有并发。
用AtomicInteger、synchronized、Lock、ThreadLocal等类来保证在代码层面上的线程安全；如果是功能上需要自主多线程处理，那么也会使用线程池ThreadPool来提高并发效率。
对高并发的处理会使用Redis的分布式锁(setnx)，将对于服务器的承载力达到一定数量后，之后的请求全部加入队列处理。
负载均衡：在代码层级上对不同的业务进行读写分离；而数据库上进行集群和主从复制。在应用服务器上对应的对每个服务器都运用lvs+keepalive模式进行服务器集群；如果硬件资源足够的话那么可以对集群节点更加多和更加分散提高并发能力和系统稳定性。
Redis是一个开源，先进的key-value存储，并用于构建高性能，可扩展的Web应用程序的完美解决方案，是线程安全的。
Redis三个主要特点：
Redis数据库完全在内存中，使用磁盘仅用于持久性。
相比许多键值数据存储，Redis拥有一套较为丰富的数据类型（list,string,sort,set,hash）。
Redis可以将数据复制到任意数量的从服务器。
