java多用户同时访问和数据库进行交互，如何能够高并发

我觉得1万的数据并发量并不大，想oracle数据库，mysql承载这些并发是没有问题的

我觉得，主要的问题在于你GPS是一直在修改的，因为车辆在不断的行驶，这样的话，可能会影响数据库的性能

我觉得，你可以用一个内存行的数据库，比如，redis，用这个来存放GPS信息，redis是基于内存的，读写要比关系数据库速度快(忽略网络因素),你可能要问GPS入库怎么弄，可以做一个定时任务，每隔多少时间来将redis的数据写入到数据库中，当然，redis也支持一些算法，比如LRU，来设置何时将数据同步到数据库

随着互联网web20网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web20网站，特别是超大规模和高并发的SNS类型的web20纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance——对数据库高并发读写的需求

Web20网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

2、Huge Storage——对海量数据的高效率存储和访问的需求

类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了25亿条用户动态，对于关系数据库来说，在一张25亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability——对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web20网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1 数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2 数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3、对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：

Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，

这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，我(robbin)也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。

一、Redis集群介绍

Redis真的是一个优秀的技术，它是一种key-value形式的NoSQL内存数据库，由ANSI C编写，遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。 Redis最大的特性是它会将所有数据都放在内存中，所以读写速度性能非常好。Redis是基于内存进行 *** 作的，性能较高，可以很好的在一定程度上解决网站一瞬间的并发量，例如商品抢购秒杀等活动。

网站承受高并发访问压力的同时，还需要从海量数据中查询出满足条件的数据，需要快速响应，前端发送请求、后端和mysql数据库交互，进行sql查询 *** 作，读写比较慢，这时候引入Redis ,把从mysql 的数据缓存到Redis 中，下次读取时候性能就会提高；当然，它也支持将内存中的数据以快照和日志的形式持久化到硬盘，这样即使在断电、机器故障等异常情况发生时数据也不会丢失，Redis能从硬盘中恢复快照数据到内存中。

Redis 发布了稳定版本的 50 版本，放弃 Ruby的集群方式，改用 C语言编写的 redis-cli的方式，是集群的构建方式复杂度大大降低。Redis-Cluster集群采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。

为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

redis-cluster投票:容错，投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉。

集群中至少应该有奇数个节点，所以至少有三个节点，每个节点至少有一个备份节点，所以下面使用6节点（主节点、备份节点由redis-cluster集群确定）。6个节点分布在一台机器上，采用三主三从的模式。实际应用中，最好用多台机器，比如说6个节点分布到3台机器上，redis在建立集群时为自动的将主从节点进行不同机器的分配。

二、单机redis模式

下载源码redis50并解压编译

wget >

MySQL中可以建立多个数据库，具体数量取决于MySQL服务器的性能和硬件资源。一般来说，MySQL服务器可以建立上千个数据库，但是也可以根据服务器的性能和硬件资源来调整数据库的数量。

现在都在清理，所有涉及国家和民生的要害部门的设备和软件，全部要求用国产，第一批2022年完成，这是国家安可工程强制要求的，你看看现在新上的数据库，那有国外厂家中标的。

这么多只为oracle背书，有点讽刺（国外的屎对这群人来说都是香的）。当初用只是无奈之举，若有选择，绝对没人用。商用软件很多都有后门，根本没有安全可言，（技术无国界）就是流氓逻辑，未来数据安全为王，oracle也会死在“闭源”上，至于说的“安全、高效”就是扯淡，国内“基础”技术越来越好，迟早要替代这些没有控制权的软件。

我的回答：银行单位选择oracle数据库，有很多的原因。

1oracle数据库是世界上第一个商用闭源关系型数据库，是比较成熟的产品。oracle具有先进的、成熟的市场经验。产品遍布各行各业，oracle的产品和技术已经广泛用在金融、电信及通信、证券、保险、能源、高 科技 、生产制造、以及政府等行业，oracle技术具有强大的领先优势。

2oracle具有高可用的架构优势，可以使用oracle rac、DataGuard、MAA等架构保障业务的稳定性、可靠性、连续性。oracle可以满足业务的高并发需求，满足OLTP各种事务处理。具有低成本、高性能、易伸缩、高可用、安全和集中管理等特点。

3oracle可以使银行提高客户服务水平、规避和控制金融风险、保证银行业务和利润的持续增长。oracle有一系列成熟的配套软件和专业的服务，可以满足银行单位的业务发展需求。尽管随着金融领域业务的变化，有去IOE和云化的变化，但是oracle的稳定性肯定是银行业务的首选，可以促进金融行业的业务转型与升级。

这样想，银行单位选用oracle数据库，合情合理！

不以泪水博同情，要以汗水赢掌声。你能作茧自缚，必能破茧成蝶！

第一，几十年前银行系统建设的时候只能选择IOE,根本没有其他的选择。

第二，目前中国的IT基础设施还无法满足银行的业务需求。

具体说oracle，他的一致性，稳定性，成熟度不是其他软件可以比拟的，你总不会希望你银行，交易所里面的钱有异常吧

不开源 安全性高 高效稳定 支持高并发

一句话，技术支持可以做到724小时，重大问题8小时内技术人员到岗，那一个开源软件可以做到。另外就是IBM的DB2也有一部分份额。

早年间MySQL和Linux都不成气候，银行是第一批使用小型机+Oracle的行业

真正的原因是银行信息化起步早。在90年代，无论是银行还是互联网都采用商用数据库。在那个时间段，MySQL和Linux都不成气候，更别提现在的大数据技术技术了。那时候，在小型机（Unix系统）上跑Oracle非常流程，MySQL根本没办法与其匹敌。

互联网企业在那个年代都热衷于Oracle，比如，阿里巴巴在2000年左右还养着全国最优秀的OracleDBA团队。只不过，后来这些互联网公司爱折腾，有实力折腾，开始用开源的MySQL替代了原来的Oracle，而银行既没有意愿有没有能力去做这件事。

核心业务强依赖Oracle，牵一发而动全身

至于到现在，银行为什么还没有替换到Oracle呢？主要是银行的业务已经成型，很多核心的功能都强依赖于Oracle，不可能轻易动，这是伤筋动骨的大事。

Oracle本身也具有很多优势

Oracle的安全级别非常高，这是MySQL不能比拟的。支持闪回和完美的数据恢复，及时硬件坏了也可以恢复到故障发生前1秒。

Oracle对于复杂的SQL场景支持得非常好，有出色的查询优化器。超强劲的CBO优化器在大部分场景可以对复杂SQL形成高效的执行计划，开发人员可以编写大量的表关联、子查询、几何运算等，我见过几百上千行的SQL或者存储过程，都有非常高的查询性能。

Oracle提供了自己的RAC架构，RAC架构推出后，即使使用普通的服务器，在低成本下实现也能实现数据的可靠性，还能提供很强的查询性能。

现在有没有Oracle的替代品呢

阿里云的 云原生数据库PolarDB完全替代Oracle数据库 ，PolarDB使用了存储和计算分离架构，可以在业务高峰期进行快速扩容，最大程度降低成本。PolarDB可以100%兼容MySQL语法，深度兼容Oracle的语法和数据类型。在2020年，阿里云已经帮助1千多家公司完成了去Oracle的工作。

这个问题其实一点都不难想象。

银行的数据极其重要，不容有半点损失和误差。

Oracle就是全球最好的数据库软件供应商。

金融行为要求的是系统稳定，系统稳定才能更好服务客户。

系统性能的要求在实时性方面在接受范围就可以，比如交易超时在60秒内等。

但是随着第三方支付的快速发展，交易量大幅度提高，则导致了银行系统在稳定性，时效性，性能方面都提升了一个或多个等级，tps的提高，系统压力也越来越大。

因此应用保证正常的情况下，数据显得更为重要。而在国内早此年，数据库的厂商还真没有，就oracle，db2，其实还有informix。

现在的情况，在国内出现一些商用的数据库，比如阿里系的，腾讯系的。

你这问题放在五年前差不多 现在你再看看有多少 现在去IOE去的差不多了

嵌入式数据库还是有很多的，这里举几个吧：

1BerkeleyDB常用嵌入式数据库有哪些

Berkeley

DB(BDB)是一个高效的嵌入式数据库编程库，C语言、C、Java、Perl、Python、Tcl以及其他很多语言都有其对应的API。

BerkeleyDB可以保存任意类型的键/值对(Key/ValuePair)，而且可以为一个键保存多个数据。Berkeley

DB支持让数千的并发线程同时 *** 作数据库，支持最大256TB的数据，广泛用于各种 *** 作系统，其中包括大多数类Unix *** 作系统、Windows *** 作系统

以及实时 *** 作系统。

2CouchbaseLite

CouchbaseLite

是一个为满足在线和离线的移动应用所开发的超轻量的，可靠的，并且安全的JSON数据库。即使在最不确定的网络条件下，亦可以给您的移动应用提供富有成效

的和可靠的信誉。除此之外，’同步门户’功能亦可以提供协作，社交互动或者是用户的更新。

3LevelDB

LevelDB是Google开源出的一个Key/Value存储引擎，它采用C编写的，支持高并发访问和写入，特别适合对于高写入业务环境。

4SQLite

SQLite是一个开源的嵌入式关系数据库，实现自包容、零配置、支持事务的SQL数据库引擎。

其特点是高度便携、使用方便、结构紧凑、高效、可靠。与其他数据库管理系统不同，SQLite的安装和运行非常简单，在大多数情况下-

只要确保SQLite的二进制文件存在即可开始创建、连接和使用数据库。

5UnQLite

UnQLite是，由Symisc

Systems公司出品的一个嵌入式C语言软件库，它实现了一个自包含、无服务器、零配置、事务化的NoSQL数据库引擎。UnQLite是一个文档存储

数据库，类似于MongoDB、Redis、CouchDB等。同时，也是一个标准的Key/Value存储，与BerkeleyDB和LevelDB等

类似。

限流算法目前程序开发过程常用的限流算法有两个：漏桶算法和令牌桶算法。

漏桶算法

漏桶算法的原理比较简单，请求进入到漏桶中，漏桶以一定的速率漏水。当请求过多时，水直接溢出。可以看出，漏桶算法可以强制限制数据的传输速度。如图所示，把请求比作是水滴，水先滴到桶里，通过漏洞并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。

来自网络

漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。

令牌桶算法

令牌桶算法的原理是系统以一定速率向桶中放入令牌，如果有请求时，请求会从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。这种算法可以应对突发程度的请求，因此比漏桶算法好。

来自网络

漏桶算法和令牌桶算法的选择

两者的主要区别漏桶算法能够强行限制处理数据的速率，不论系统是否空闲。而令牌桶算法能够在限制数据的平均处理速率的同时还允许某种程度的突发流量。如何理解上面的含义呢？漏桶算法，比如系统吞吐量是 120/s，业务请求 130/s，使用漏斗限流 100/s，起到限流的作用，多余的请求将产生等待或者丢弃。对于令牌桶算法，每秒产生 100 个令牌，系统容量 200 个令牌。正常情况下，业务请求 100/s 时，请求能被正常被处理。当有突发流量过来比如 200 个请求时，因为系统容量有 200 个令牌可以同一时刻处理掉这 200 个请求。如果是漏桶算法，则只能处理 100 个请求，其他的请求等待或者被丢弃。

数据库建立多表关联，关键业务数据字段和查询字段建立索引，对唯一性建立好，同时多任务并发时程序设计时注意数据的合理性检验和用户处理数据有问题时的友好提示见面，建立好的结构文档说明，同时对关键字段的关系型作好记录，有效地设计多表的结构安排，尽量减少数据的冗余，同时又要避免对历史数据的影响，保持良好的数据管理

以上就是关于java多用户同时访问和数据库进行交互，如何能够高并发全部的内容，包括:java多用户同时访问和数据库进行交互，如何能够高并发、关系型数据库的局限性有哪些难以满足高并发读写的需求、高性能高并发网站架构，教你搭建Redis5缓存集群等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！