公司项目并发量都特小，自己如何实际接触高并发项目？
如果你是一个工作刚不久的巨婴，那么首先，不要急于学习大型网站的架构设计，此时此刻做任何项目都可以学到很多东西，并发量不高的项目你可以多学习学习代码设计，要是工作不那么忙你还可以在公司学习。任何产品不可能一开始的时候就是高并发架构。但是我们要时刻准备好迎接大流量。如果你确实希望能够直接接触高并发项目，那也不是不可以。
我给你一个实际操作的思路。首先你需要了解jmeter工具，高并发的项目通常会用它来进行并发测试。并发我们通常会分为两种，一种是读并发，一种是写并发。模拟读并发第一阶段：正常情况下，我们编写一个接口都是直接访问数据库获取数据，那这样肯定是占用数据库连接的，所以并发数不会很高。第二阶段：我们为数据添加缓存，访问时我们先访问缓存，比如redis，如果缓存中没有数据我们再从数据库中读取，这里就会涉及到缓存雪崩和穿透的问题。
这些问题咱们可以忽略不计，因为解决办法很简单，而且有很多种。添加缓存就减少了数据库压力，更重要的是我们增加了请求的IOPS（吞吐量），也就意味着我们的服务器一秒钟可以处理更多的请求，也就提高了并发量。第三阶段：当我们的缓存处理的IOPS比我们的服务器最高支持的并发数还高，比如Tomcat优化的好的话可以有1.5k左右（有人说可以达到6k），不过我觉得这个跟你机器的内存和tomcat的配置有关，咱们暂且假定是1.5k。
如果你要超过1.5k的并发，那么此时你就需要增加服务器或者换一种并发量更高的服务器。我们以增加服务器为例，你可以添加1台服务器来支持更高的并发，然后通过nginx进行负载均衡，将流量分配到两台tomcat中。我们知道nginx的最高并发可以达到3W，也就是意味着你可以添加20台tomcat。第四阶段：当nginx成为了我们的并发瓶颈，我们就要做nginx集群了。
这也意味着我们需要将一个地区划分成多个小地区，每个地区配置一个公网nginx。而这种做法有两种，一种是通过网络路由层增加控制来实现分发，一种是通过硬件来实现，硬件的我没操作过，自己实践也不实际，因为很贵！当然，我们并不能直接通过增加最高并发量就能处理并发，比如数据库层面中途我们就需要改成主从机制，采用分库分表或者使用mongodb这种高吞吐量的数据库来做。
比如我们的机器配置也需要增加等。模拟写并发写并发跟读并发的区别主要在于写的时间往往比较长，读的时间我们通过缓存来提高，但写库这个动作我们并不能通过缓存来处理，此时就需要我们增加消息队列MQ，最终走向MQ的集群。增加MQ以后我们的请求只是把写库这项任务添加到队列中，然后一条一条地执行，但是用户发起的请求我们立即返回成功标志。
这样可以不占用服务线程。也就提高了并发量，同时也需要修改我们的业务，比如正常下单是订单入库后返回成功，并发量上来后我们就需要调整为订单加入队列后成功，并没有入库，那么此时不能告诉用户下单成功，而是提醒用户正在下单，然后前端每1秒钟去查询订单看是否存在，如果存在再提示下单成功。最后总的来说，我们知道了一套高并发的常见处理方式和原理，我们就可以自己去模拟一下。
讲真的在公司基本学不到啥东西，一般都是靠自己做项目来完成一些自己想要的效果或者自己想实践的技术和经验。我自己就开发了一个代码开发平台，你也可以了解一下，叫懒猴子CG。前端用的nuxt，后端用的springboot，基本都不怎么架构，但是从前端到后端基本都是我一个人开发的，所以还是会学到很多东西。即使流量大了，我也有办法撑起来，这就是自己做项目去实践的一个好处，可以经历一下从无到有的整个过程。
如何看待有些满嘴高并发，编码能力却稀松平常的程序员？
一般公司并发能有一百就很不错了，上千已经是业内有名了，上万已经是领头羊了。但是工业软件另说，采集器一秒一个数据，上万采集器一秒就一万的数据。满嘴高并发的程序员大部分都没有高并发经验，因为高并发更多的面对波峰请求，容错处理，容灾处理，带损服务，大数据处理，防御机制做得多，纯粹的高并发离开业务都是不靠谱的，比如直播类的并发和12306抢票处理就不一样，电商的双十一和大型图片存储中心的并发处理又不一样，游戏的高并发又不一样。
编码能力不行又满嘴高并发这必须是个玩虚高手，搞关系他很行，甩锅也是一般好手。我有幸参与过秒请求超过5万的项目，说实话，很痛苦，光是扩容和修改数据库都让我熬了好多个通宵。后来实在是太痛苦了，把cpp换成可以热更新的语言，全部重写了一遍。即使我已经是bug率很低了，一天造一个，久了也受不了。热更要停机，秒请求5w，更新停一次机我就要熬到凌晨四点多，这个时候请求量还上五千。
