软件刚开始的时候是为了实现功能，随着信息量和用户的增多，软件架构变得越来越复杂了，大数据和高并发成了软件设计必须考虑的问题。那么，要解决好大数据和高并发这个问题，就是要把复杂问题简单化，核心就是要把握本质。
比如商品促销秒杀活动，几万人登录系统抢几个限量的商品，该如何应对？
首先，在商品还没被下单之前不能只让一个人看到商品，要保证大家都能看到商品，也不能造成服务器瘫痪，这样就大家都没法抢购，最终谁能抢到商品，那么就得拼运气和硬实力了（网络快慢、触发按钮的时间点等）。
其次，如果是有上万人都同一时间触发了购买，并发的情况下，不能把商品给所有人，那么到底要把商品给谁。
在这种情况下，并发处理首先想到的是通过优化应用层的代码来解决，比如锁同步，在多个线程进来时，用JAVA中的syncrinized关键字进行控制，只能一个个的访问。当锁也有两种类型，一种是JAVA中的对象锁，用于线程同步，另一种是数据库的锁，如果是分布式的系统，则只能利用数据库的锁来实现。
hibernate中关于锁提出了两个概念：乐观锁、悲观锁（即传统的物理锁）。乐观锁意思是不锁定表的情况下，利用业务的控制来解决并发问题，这样即保证数据的并发可读性又保证保存数据的排他性，保证性能的同时解决了并发带来的脏数据问题。
hibernate实现乐观锁的机制要求在现有表中增加一个冗余字段，version版本号, long类型。
原理：1）只有当前版本号》=数据库表版本号，才能提交
2）提交成功后，版本号version ++
实现很简单：在ormapping增加 一属性optimistic-lock='version'即可，以下是样例片段
那么在股票实时交易系统、工业大数据系统、银行交易系统这些会实时产生大量数据的情况下，又要如何考虑？ 工业大数据系统中的设备传感器，一个传感器每秒钟就有一条数据记录产生，一天下来数据量×60×60*6 条记录，一月下来这个表记录数量多大？ 再加上传感器数量至少两位数，oracle中一张表的记录数超过100w后 查询性能就很差了，如何保证系统性能？ 大数据量的系统，必须考虑表拆分-（表名字不一样，但是结构完全一样），通用的几种方式： 1）按设备类型分，我们可以一种类型设备作为一个表，甚至一台设备一张表 2）按时间轴拆分，当日数据一个表，当月数据一个表。 3）利用oracle的表拆分机制做分表 当然，表拆分后我们的应用得做相应的适配。单纯的or-mapping也许就得改动了，比如部分业务得通过存储过程等来实现便捷访问。 此外，我们还得考虑缓存 这里的缓存，指的不仅仅是hibernate，hibernate本身提供了一级二级缓存。这里的缓存独立于应用，依然是内存的读取，假如我们能减少数据库频繁的访问，那对系统肯定大大有利的。比如一个电子商务系统的商品搜索，如果某个关键字的商品经常被搜，那就可以考虑这部分商品列表存放到缓存（内存中去），这样不用每次访问数据库，性能大大增加。 简单的缓存大家可以理解为自己做一个hashmap，把常访问的数据做一个key，value是第一次从数据库搜索出来的值，下次访问就可以从map里读取，而不读数据库；专业些的目前有独立的缓存框架 比如memcached 等，可独立部署成一个缓存服务器。 当然，要正确处理好大数据和高并发还有很多事情要处理：1）页面静态化；2）使用储存过程；3）批量读取；4）延迟修改 -5）使用索引等。 还有一种土豪办法是建高并发站点服务器来进行分流，淘宝后台服务器据说有十多万台：
1）集群 - 将并发请求分配到不同的服务器上，可以是业务服务器，也可以是数据库服务器。技术可以通过负载均衡技术LVS，haproxy，web集群技术如nginx 反向代理tomcat集群或者apache集群，缓存技术如Varnish，memache,redis,mongodb，数据库集群如mysql的AB复制，通过开源的mysql中间件如Atlas,cobar,TDDL实现数据库的读写分离等等
2）分布式 - 分布式是把单次请求的多项业务逻辑分配到多个服务器上，这样可以同步处理很多逻辑，一般使用与特别复杂的业务请求。
3）CDN - 在域名解析层面的分流，例如将华北地区的用户请求分配到华北的服务器，华南地区的用户请求分配到华南的服务器。
土人创新是一个接地气的创新项目孵化工坊，致力于做你专属的技术合伙人，聚焦“网络安全、移动应用、物联大数据”三大方向，为客户提供信息安全化、应用便捷化、数据可视化、分析智能化服务。
联系客服
