① 通过Redis消息队列实现大文件处理
一、故事背景
1、读取离线文件数据，再通过【离线数据】作为条件，查询第三方接口，返回最终的结果，再入库。
2、 业务逻辑是很简单， 读取文件、查询接口、返回数据集、入库 四步。
3、业务特性：第三方接口调用400毫秒(ms) 。
如果用普通单线程去跑算500毫秒一个请求，一天也就跑8W多数据量，20多亿的数据不知道跑到猴年马月了。
二、处理方案
A) 初步方案采用ganymed-ssh2(文件都存储在Linux服务器上) 来读文件，Redis来存储消息、多线程来提升处理能力。
B) 流程图：
三、呈现问题
四、优化问题
最终流程图：
1、 通过Redis做一个计数器 每读取一行记录数值，即使服务终止后，先从Redis读取这个数值
再通过cat指定行数开始读数据即可。
2、 通过取模拆Key 分片到不同小Key存储 ，降低单个节点存储压力，也充分利用了存储资源。
3、Redis Push 提供了批量方式(leftPushAll) ，可以指定读取行数再批量入库，而pop并没有提供批量 只能一个一个pop。
4、消费者通过多线程pop、再分发到线程去处理。
五、总结问题
② 常用的消息队列
一、redis消息队列和kafka消息队列的比较
1、Redis作为消息队列
Redis的pub-sub模式非常像西式快餐一样,快产快消,全都是因为Redis是使用内存来做存取,所有你生产的消息立马会被消费者一次性全部处理掉,并且没有留下任何痕迹, 同时因为内存总是宝贵的,所以内存上会有限制,当生产者以及消费者上来的时候也会对redis的效率,还有Redis在处理发布和消费big size(10K+的文件)的数据的时候会表现出无法忍受的缓慢
如果有以下场景可以考虑使用Redis作为消息队列：
a、如果你的需求是快产快消的即时消费场景,并且生产的消息立即被消费者消费掉
b、如果速度是你十分看重的,比如慢了一秒好几千万这种
c、如果允许出现消息丢失的场景
d、如果你不需要系统保存你发送过的消息,做到来无影去无踪
e、需要处理的数据量并不是那么巨大
2、KafKa作为消息队列
KafKa的设计精妙,支持分布式,高可用的部署,并且对一个大的队列采用分成多个Partition(分区),来提高消息入队的吞吐量,分而治之的思想. 并且消费的时候支持group的概念,能够支持多个客户端消费同个队列,并且一个group中可以增加consumer的数量来扩展消费的处理量.
KafKa不熟生产者数量的影响,因为吞吐量足够支撑,即使在廉价的单机服务器上也可以有10万每秒的消息传输量,并且消费者是想什么时候消费都可以,消息它就在那里,十分灵活,不用担心来无影去无踪的恐慌.能把消息持久化,并以一定的策略(例如一定时间内删除,或者到达多大容量的时候清空)
当有一下场景的时候你可以考虑使用KafKa作为消息队列：
a、如果你想要稳定的消息队列
b、如果你想要你发送过的消息可以保留一定的时间,并不是无迹可寻的时候
c、如果你无法忍受数据的丢失
d、如果速度不需要那么的快
e、如果需要处理数据量巨大的时候
③ 高并发用消息队列会延迟，还有什么好方法解决
首先你要知道队列的应用场景在于哪里。一般在需要后台大量逻辑处理或计算资源的情况下采取队列，同时也可以提高前端的用户体验。
举个例子：微博-关注/粉丝，假如你有1000个粉丝，你发了一条微博，这时候1000个粉丝都会收到你的动态，消息队列便适合在这样的场景下用。原因：
1 推送1000个动态数据是耗时操作，而发送微博页面需要尽快响应，因此可将该任务放置到队列；
2 你发送了微博之后是即时生效的，但粉丝收到微博允许有些许的延迟，通过队列的方式实现也契合该需求；
3 针对队列的处理可以采取高性能的集群架构实现，架构上实现了关注点分离，系统在扩展方面更加灵活
④ 消息队列(mq)是什么
是生产者先将消息投递一个叫队列的容器中，然后再从这个容器中取出消息，最后再转发给消费者。
消息队列是 Microsoft 的消息处理技术，它在任何安装 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。
消息队列网络是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。
消息队列的类型介绍：
消息队列目前主要有两种类型：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息。包括消息队列键值、用户ID、组ID、消息队列中消息数目等等。
消息队列就是一个消息的链表，可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。
⑤ activemq消息队列怎样解决高并发
Queue模式获取之后,消息队列中消息就应该会被删除: Topic模式 在持久化之后,才可能被拿走之后,依然存在
⑥ java高并发文件上传下载设计问题
说实话 从软件或代码角度 没辙 都是长连接 逃不掉的
只能从系统设计上去考虑，大致上会有以下这两种思路（基本上是都用的）：
1、对于所有的上传的文件，根据随机生成的名称或code取hash用策略取模，分服务器存/取文件，保证不触及io瓶颈，内部文件同步策略自己考虑
2、对所有请求，分pop点分发，根据用户的物理地址选择相应较近的pop点处理请求(当前pop请求已满则顺延至下一pop点，依次类推)
⑦ 分布式缓存主要用在高并发环境下的作用
分布式缓存主要用在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显着提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。
当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。
⑧ Java操作高效并发操作读写文件,消息持久化到本地读取
楼主，如果写，先判断要写多大的文件、然后分段写，各线程写自己的段
如果读，也是先得到文件大小、再分段，然后各线程读自己的段
⑨ 消息队列的使用场景是怎样的
个人认为消息队列的主要特点是异步处理，主要目的是减少请求响应时间和解耦。所以主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时由于使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦和。
使用场景的话，举个例子：
假设用户在你的软件中注册，服务端收到用户的注册请求后，它会做这些操作：
校验用户名等信息，如果没问题会在数据库中添加一个用户记录
如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
发送给用户一个包含操作指南的系统通知
等等……
但是对于用户来说，注册功能实际只需要第一步，只要服务端将他的账户信息存到数据库中他便可以登录上去做他想做的事情了。至于其他的事情，非要在这一次请求中全部完成么？值得用户浪费时间等你处理这些对他来说无关紧要的事情么？所以实际当第一步做完后，服务端就可以把其他的操作放入对应的消息队列中然后马上返回用户结果，由消息队列异步的进行这些操作。
或者还有一种情况，同时有大量用户注册你的软件，再高并发情况下注册请求开始出现一些问题，例如邮件接口承受不住，或是分析信息时的大量计算使cpu满载，这将会出现虽然用户数据记录很快的添加到数据库中了，但是却卡在发邮件或分析信息时的情况，导致请求的响应时间大幅增长，甚至出现超时，这就有点不划算了。面对这种情况一般也是将这些操作放入消息队列（生产者消费者模型），消息队列慢慢的进行处理，同时可以很快的完成注册请求，不会影响用户使用其他功能。
⑩ 高并发三种解决方法
处理高并发的方法不止三种。
1：系统拆分
将一个系统拆分为多个子系统，用bbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。
2：缓存，必须得用缓存
大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发，没问题的。所以可以考的虑考虑项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。
3：MQ(消息队列)，必须得用MQ
可能还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，那高并发绝对搞挂系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。
所以该用mysql还得用mysql，用MQ，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是可以的。
4：分库分表
可能到了最后数据库层面还是免不了抗高并发的要求，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。
5：读写分离
这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。