bio是什么意思？
bio
linux内核中通用块层的核心数据结构
bio是linux内核中通用块层的一个核心数据结构，它描述了块设备的I/O操作，联系了内存缓冲区与块设备。
中文名
块设备的输入/输出
外文名
bio
全名
Block input output
类型
程序
用途
描述块设备的输入/输出操作
简介bioTA说
如何才能成为java架构师？我为大家来分析一下？
首先架构师不是那么好当，技术实力一定要过关，要具有架构师的思想，其次架构师是企业级开发所需的Dubbo框架、zookeper基本原理、redis分布式缓存、JVM性能优化，Nginx+apache+Tomcat集群部署、大数据hadoop,Hbase实时计算spark、storm、数据分析分词和权重等核心技术。
如何成为一个优秀的架构师呢？我用七张图片来告诉大家。
另外的四张图片想成为架构师的可以私信我，每天更新java架构师技术视频资料。
大家可以先学习下分布式锁的实现：
链接: 密码: umu3
梦想成为一名牛逼的架构师，10年前的我也不曾例外，但是怎样才能成为JAVA架构师？要成为架构师应该做哪些准备？学好哪些技术和知识呢？以下是我自己的成长经验，分享给大家：
提升专业技能
- 首先是要有扎实的基础知识，阅读经典书籍，比如设计模式，算法，数据结构等。
- 对于某一个技术领域需要精通一门技术，要达到精通是一个漫长的学习，需要不断的学习和实践。
- 写得一手优秀的代码，多练习。
- 学会阅读别人的代码，并给出一些较合理的建议。
- 至少精通一门编程语言(核心竞争力)，在此基础上学习了解更多的语言，从而让你站在一个更高的角度认知代码，其实语言之间都是相互借鉴的。
- 如果1-5都做得很好了，就去看看架构设计方面的书籍，比如企业应用架构模式，架构之美等等。
- 看看不同行业的企业对于架构师的技术要求和标准，然后结合自己当前所处的行业和你自己的技术特点，有选择性的学习一些自己感兴趣的技术或者方法。（文末有架构师具体职责、阿里架构师面试真题，帮助大家更进一步了解架构师这个岗位）
提升软技术
- 多学习、多练习沟通表达能力，这能让你成为一名更加优秀的架构师。
- 技术更新迭代快，保持空杯心态，学习了解新技术，保持饥渴学习和耐得住寂寞的赤子之心，不要让自己技术落伍。
- 与不同的技术、编程语言、设计模式和结构等（甚至是它并没有在日常中给予你直接的帮助）打交道。你永远都不知道这些知识是否会在未来派上用场，但是对你绝对是有益无害。
- 有机会多做知识分享，因为你一旦分享了知识，你就会对这门技术有深刻的印象，同时也能树立在同事中的良好的技术形象，从而赢得更多的专家影响力而不是职位影响力。
想了解完整架构师职责（含架构师定义+岗位职责+具备能力），查看我的往期悟空问答，地址：
想了解阿里架构师面试真题，查看我的头条号文章【阿里java架构师面试128题含答案：分布式架构+Dubbo+多线程+Redis】，地址：
以上，希望对准备或者已经开始架构师学习的朋友有所帮助。原创码字不易，觉得不错请点赞支持，送大家【阿里java最全面试题目及答案120个】，发送【120】立即领取。
首先呢，我觉得工作3年左右开始考虑这个事儿是正常的，写了一定的功能，接触了一些框架了，可能遇到了不少坑，也加了不少班，但是忽然想起来做的东西零零散散，找不到精深的方法。
这个问题不是你一个人的问题，也不是做程序才会遇到的问题，只不过软件工程是实践科学，基本都是反着来的，先做了，然后找资料再学原理，基于此，如果说你想利用空闲时间正向地梳理这些东西的话，还是先从基础出发（以java web系来说，我最熟悉的）：
1、java core，基础，集合，多线程，jvm的基础
2、框架方面：spring、springmvc（restful的请求原理）、spring boot（这里只是配置和使用，不用急于求成，spring的东西很多）
3、数据库方面（1、mysql、oracle；2、常用连接池：druid、hikari等）
4、rpc：httpclient，dubbo，thrift，grpc（使用没啥难度、主要是学习这几种典型rpc的架构和使用场景）
5、nosql：redis、mongodb、cassandra、memcache（使用场景、集群方式、常见的数据结构、使用场景、缺点很重要）
6、业务工具（1、POI：用来导入、出excel和word，功能强大～；2、javax mail发送邮件；等等）
7、总结一下常用的算法、不一定是面试常考的，基础排序和查找算法、链表的操作、图相关的操作等，实践中可能遇到的少，但是思维要有
8、如果是后端工程师，建议适当做一些前端开发了解一些前端的技术，是你未来更好的架构和理解前端和协作打下基础，这里包括常见的前端框架（angular、vue、react）、打包工具（webpack、gulp等）、原生js的dom操作
9、了解一些大型架构的细节也是学习和成长的方式。
。。。
其他的东西还有很多，其实你自己列一列这些细节，再有几年，就会有自己的体系了。
1秒1000并发，高并发需要什么样的服务器？
硬件层面需要根据数据量，业务复杂度一起综合评估的，建议先买两台云主机（4核8g内存）搭建集群环境就行。后继再根据实际需要扩展。
软件层面：
一、如果是写入操作的，应该：
1.1 使用消息队列来异步处理（如activemq等），避免消息堵塞
1.2 使用MongoDB的批量写入功能，比如每1000条数据才写入一次
二、MongoDB部署为集群模式，可以分散压力
三、如果是读取操作，可以考虑加入redis，将热点数据进行一级缓存
一、服务器配置优化
首先我们知道几个概念：
MongoDB是NoSQL面向文档型存储数据库，属于重内存的类型，特别是在MongoDB 3.2默认的 WiredTiger引擎下，默认会占用大量的内存来保证自身性能。
因此MongoDB所需要的服务器，以题主使用的云主机为例，选型思路主要是重存储型云主机，为了保证Mongo集群的读写性能，需要以SSD云盘前提下尽可能大内存的主机，同时vCPU也不能太低会影响压缩存储效率。
如果技术储备不够，在参数调优、版本升级、数据迁移中有问题怕踩坑，可以采用一些成熟的云服务提供商的基于容器的云原生Mongo Operator产品，这样可以少踩许多坑。
参考网易轻舟这类商业化中间件
二、软件层优化
简单介绍下我在MongoDB优化中的思路：
MongoDB主要包括mongod和mongo两个进程。
mongod是处理MongoDB系统的主要进程。它处理数据请求，管理数据存储，和执行后台管理操作。当我们运行mongod命令意味着正在启动MongoDB进程，并且在后台运行。
mongo则是一个命令行工具用于连接一个特定的mongod实例。当我们没有带参数运行mongo命令它将使用默认的端口号和localhost连接
1、参数调优
操作系统OS层面连接数优化
要提供高并发的响应能力，首先要考虑提升MongoDB本身的服务能力，mongod进程的连接数主要是受到操作系统的默认文件描述符和进程/线程数限制。
以centos为例，需要通过ulimit -a 查看open files是否够大，如果太小可以通过以下命令设置用户/进程允许打开的文件句柄数。
ulimit -n 1048576 ulimit -u 524288
参考资料：点————看
脱离实际业务谈高并发都是纸上谈兵，不切实际！
尽管我们聊到高并发时候一定要结合实际业务场景去设计、去优化，但是高并发的设计是有方法论的。
首先我们要区分当前的业务是读多写少还是写多读少的场景。
读多写少
如果是读多写少的业务场景，其实1000qps是不高的，更不需要什么高端的服务器，我18年负责的一个业务，典型的读多写少，高峰期并发达到4000QPS，也只是用了4台2C4G的云服务器+16G的Redis集群就扛住了，不需要做额外的开发，一个旁路缓存策略就搞定。仅是Redis单机模式就能达到理论的10万QPS，所以1000并发算啥？
旁路缓存原理
合理的运用缓存提高程序的访问性能只是特定场景下的一种手段，实际上针对读多写少是有很多手段的，很多时候在网络这块就可以解决掉大部分的流量，比如CDN技术、4层负载、7层负载。
读少写多
上面我说了读多写少的场景，这种场景相对比较简单，与之相对应的就是读少写多的场景了，这种场景因为要大量的写数据，大部分的业务场景数据最终都会写入数据库或者文件，这时候流量无法前置处理，数据所在服务器最终成为压力的一方，因此在高并发情况下，为了保证高可用（数据不丢失、不脏读、不错误），还是有一定的挑战的。
常见的一种手段就是利用队列排队写入，削峰填谷以均衡服务器的压力。这是在放弃一定的并发性能来获取高可用的折衷手段。这个时候一定要结合具体的业务场景来做设计，并发量级有多大，哪些地方可以牺牲部分的性能，哪些地方可以牺牲一定的高可用，哪些地方可以不用强一致性，只要最终一致性即可等等。
一个经典的场景是采用kafka来应对高并发的数据写入，kafka可以采用分区的技术多台机器消费生产者的消息。
kafka
最后
尽管1000并发不算高，但是在实际开发中我们还是要小心面对这种具有“一定量级”的业务，在保证服务正常运行的前提下，还要注意并发读写带来的一系列问题，例如幂等性保证、数据的一致性保证等等。
我是“Java架构设计”，欢迎关注，持续为您分享优质技术内容。