• 关于

    不能工作状态问题怎么解决

    的搜索结果

问题

[@倚贤][¥20]与技术完全无关,却富有挑战的问题

嘟嘟老爸 2019-12-01 20:26:43 627 浏览量 回答数 2

回答

1.第一个问题通过数据版本,也就是所谓的乐观锁解决。 2.先写日志log,然后ack机制。其实很多这种方式被很多应用所用到比如mysql。 3.用户注册本身这个功能不属于高频调用,所以性能上不需要考虑太多,直接悲观锁实现即可。而且这种可能性非常低,就算失败,那么返回给用户一个能理解的失败信息即可。######回复 @sixliu:谢谢回复靠谱的回答真不多我再等等看...######回复 @花歌:第二个可能没太理解你的场景######谢谢咯~1和3可以,我看看还有什么别的方案,差不多也就这么做了,2的话再考虑考虑吧感觉还是有点不适用场景###### 三个问题,其实就是同一个并发的问题,###### 都是并发中会出现的问题。 1说的在内存里的情况,就是2。 1说的在数据库中的情况,就是3。 在数据库中,数据库自己会有锁来解决这个问题,遇到这种情况会修改失败,程序中捕获这种异常做处理返回给前台就可以了。 在内存中,单机单进程单线程,会有顺序,因此没有问题。多机或多进程或多线程操作同一数据,会出现此问题。一种实现方式是加锁,相当于仿照数据库那样的实现,内存正在被修改时,其他的修改会被阻塞或者异常终止。另一种方式是通过队列实现顺序操作,所有的修改都发送到一个程序修改。######让我想想,嗯差不多,回答比较靠谱,谢了先其实...我用的是nodejs全异步操作,前面的数据库操作没完成,后面的也可以进入函数,如果网络延迟,就会造成执行完成顺序和开始执行顺序不一致...等等想一会再问你哈###### 1.是设计上的问题 两个操作如果有先后顺序 就得先后执行  一个操作完了之后再下一个操作 不可能明知道有一前一后却还要非得一起 2.这个就是非常典型的数据库事务 就是保证多个不相关的操作的原子性 只要其中一个出问题就全部回滚 不存在有的成功有的失败 事务还是个挺复杂的东西 mongodb都还不支持事务 多服务器之间分布式的事务也是有些麻烦的  3.同时的操作数据库自己会进行锁的处理 对数据库来说还是一前一后  如果某个字段设置了唯一索引 那后面的那个必然会出错 代码里正常处理就可以了 所以用户名不唯一的处理有两个地方 一个是在插入之前 一个是在插入时抛出唯一索引异常   当然也可以在新建用户这一整个操作上加锁 全局同时只能有一个用户在新建 不过这样可能效率不高 ######问题1现实情况就是这样用户以为他的操作有顺序但基于连接池算是并发操作即时不用池那也是异步操作不能保证顺序所以只能考虑数据库锁时间戳问题2还没到数据库呢...只考虑多个内存中的对象操作问题3现在就是这样处理的###### 1.加锁 2.加事务控制 3.异常捕获与处理 工作不满一年吧######不好意思...工作6年多了开发经验10多年问题1暂时用乐观锁解决了问题2事务控制个毛线问题你可能是没读清内存中的几个对象而已和数据库无关就是事务也得自己实现这话谁都会说我想听的是备忘录模式这种...到底怎么做能优雅点还是我从需求设计上可能有问题问题3靠数据库唯一约束出错返回太暴力现在就是这么做的也可以数据库加锁怕影响性能###### 1,updateusersetstatus=2wherestatus=3andid=1; 2,用户名设置唯一索引。###### 可以用现在拷贝上操作,再合并的方法解决。1、按顺序合并。2、按状态合并。3、按索引合并。

优选2 2020-06-09 10:36:32 0 浏览量 回答数 0

回答

1.第一个问题通过数据版本,也就是所谓的乐观锁解决。 2.先写日志log,然后ack机制。其实很多这种方式被很多应用所用到比如mysql。 3.用户注册本身这个功能不属于高频调用,所以性能上不需要考虑太多,直接悲观锁实现即可。而且这种可能性非常低,就算失败,那么返回给用户一个能理解的失败信息即可。######回复 @sixliu : 谢谢回复 靠谱的回答真不多 我再等等看...######回复 @花歌 : 第二个 可能没太理解你的场景######谢谢咯~ 1和3可以,我看看还有什么别的方案,差不多也就这么做了,2的话 再考虑考虑吧 感觉还是有点不适用场景###### 三个问题,其实就是同一个并发的问题,###### 都是并发中会出现的问题。 1说的在内存里的情况,就是2。 1说的在数据库中的情况,就是3。 在数据库中,数据库自己会有锁来解决这个问题,遇到这种情况会修改失败,程序中捕获这种异常做处理返回给前台就可以了。 在内存中,单机单进程单线程,会有顺序,因此没有问题。多机或多进程或多线程操作同一数据,会出现此问题。一种实现方式是加锁,相当于仿照数据库那样的实现,内存正在被修改时,其他的修改会被阻塞或者异常终止。另一种方式是通过队列实现顺序操作,所有的修改都发送到一个程序修改。######让我想想,嗯 差不多,回答比较靠谱,谢了先 其实...我用的是nodejs 全异步操作,前面的数据库操作没完成,后面的也可以进入函数,如果网络延迟,就会造成执行完成顺序和开始执行顺序不一致... 等等想一会再问你哈###### 1. 是设计上的问题  两个操作如果有先后顺序  就得先后执行   一个操作完了之后再下一个操作   不可能明知道有一前一后 却还要非得一起 2. 这个就是非常典型的数据库事务   就是保证多个不相关的操作的原子性  只要其中一个出问题就全部回滚  不存在有的成功有的失败  事务还是个挺复杂的东西   mongodb都还不支持事务  多服务器之间分布式的事务也是有些麻烦的   3. 同时的操作 数据库自己会进行锁的处理  对数据库来说还是一前一后    如果某个字段设置了唯一索引  那后面的那个必然会出错  代码里正常处理就可以了   所以用户名不唯一的处理有两个地方  一个是在插入之前  一个是在插入时抛出唯一索引异常      当然也可以在新建用户这一整个操作上加锁   全局同时只能有一个用户在新建  不过这样可能效率不高  ######问题1 现实情况就是这样 用户以为他的操作有顺序 但基于连接池 算是并发操作 即时不用池 那也是异步操作 不能保证顺序 所以只能考虑数据库锁 时间戳 问题2 还没到数据库呢... 只考虑多个内存中的对象操作 问题3 现在就是这样处理的###### 1.加锁 2.加事务控制 3.异常捕获与处理 工作不满一年吧######不好意思... 工作6年多了 开发经验10多年 问题1 暂时用乐观锁解决了 问题2 事务控制个毛线 问题你可能是没读清 内存中的几个对象而已 和数据库无关 就是事务也得自己实现 这话谁都会说 我想听的是 备忘录模式 这种... 到底怎么做能优雅点 还是我从需求设计上可能有问题 问题3 靠数据库唯一约束出错返回太暴力 现在就是这么做的 也可以数据库加锁 怕影响性能###### 1,update user set status=2 where status=3 and id=1; 2,用户名设置唯一索引。###### 可以用现在拷贝上操作,再合并的方法解决。1、按顺序合并。2、按状态合并。3、按索引合并。

爱吃鱼的程序员 2020-05-29 20:15:24 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

4核处理器,4G内存,500G硬盘,5兆网速,四个同时连接数服务器瘫痪

abcabc521 2019-12-01 21:00:31 8634 浏览量 回答数 2

问题

不搞清这8大算法思想,刷再多题效果也不好的 7月23日 【今日算法】

游客ih62co2qqq5ww 2020-07-29 11:10:09 3 浏览量 回答数 1

问题

程序员报错行为大赏-配置报错

问问小秘 2020-06-11 13:18:25 6 浏览量 回答数 1

回答

这帖子都喷成这样了 - - 我自己的使用经验来看 SLB的稳定性是跟RDS有的一拼的 用了一年多的SLB真正因为SLB自身原因引起的故障寥寥无几 大部分情况是服务器超载了SLB返回503 印象中没有因为SLB自身故障导致网站挂掉的 个人觉得SLB更侧重于提升网站的可用性 提升负载能力倒是次要了 当你网站需要多台服务器进行热备的时候SLB的重要性不言而喻 至于多台机器提升性能 我自己是用来看很少从性能方面考虑SLB 如果你真的需要两台一起工作才能承载整个网站访问 那么一台down掉 另一台也会因为承受不住压力down掉 这种情况下部署SLB是无意义的 只有在确定单台能满足要求然后横向扩展时才能发挥SLB提高网站可用性的作用 还有一个问题是很多站长部署SLB的时候忽略了自身的技术水平 SLB并不是一个简单可以部署的功能 1 有多少网站完全吃掉了高配服务器的所有资源,迫不得已必须上SLB提升负载能力的? 2 有多少站长有能力去解决部署SLB过程中需要解决的一系列问题的,比如最简单的数据同步。 3 部署之前是否认真了解了SLB的技术实现,对可能出现的问题进行考虑以及认真的在部署前进行测试。 对于SLB而言如果对网站运行稳定性有很高要求,那么一定要上的,但是要经过仔细的测试。如果站点比较小的话还是走单服务器吧 实现简单也够用 至于IP隐藏 SLB已经帮你做了 外面看见的都是VIP 看不到后面服务器IP的 同样在SLB后的机器需要通过X-FORWARD-FOR来获取真实客户的IP地址 否则的话你看见的全部是内网地址 ------------------------- 回 33楼(alilab) 的帖子 难道是人品问题么 - - 我们从一年多前开始用阿里云就在使用SLB了 那时候功能还没现在的完善 但是我用到现在也只遇到过一次因为SLB故障我无法创建修改服务器集群 并没有出现过无法访问的问题…… 用了这么久SLB跟RDS是出问题最少的…… 每次工单问我们都有记录 真正问题原因是SLB引起的真心一次没有…… 而且SLB曾经多次在我们一台挂掉服务器状态的情况下成功把所有访问转移到另一台服务器 保证了网站没中断 ------------------------- 回 39楼(billz) 的帖子 数据不能随便说 但是我们用了这么久的确没出现什么问题 相比较于云服务器出各种诡异问题 SLB已经稳定的相当多了 弱国你觉得阿里云SLB稳定性不足 你可以自己实现一个SLB 跟阿里云的对比一下 ------------------------- 回 43楼(gdliwt) 的帖子 用SLB遇到的技术方面的麻烦远比你多花钱来的麻烦得多…… ------------------------- 回 45楼(gdliwt) 的帖子 我是只遇到过一次 但是遇到的多的我不知道怎么回事 而且貌似越新建的的SLB越不稳定 我们那个VIP建立起来就没变过到现在 很少看见用SLB很久的出来说 反倒是新用SLB的问题不少 ------------------------- 回 46楼(gdliwt) 的帖子 我们一般留在工单里根阿里云秋后算账了  - - 一般出现问题反馈对于阿里云来说也是改正bug的好机会

twl007 2019-12-02 01:08:31 0 浏览量 回答数 0

问题

想转行吗?“数据分析师”将成为接下来最热门的职业

zhedianshi 2019-12-01 20:57:21 16874 浏览量 回答数 26

回答

该怎么写,简单的就行######https://zb.oschina.net/###### 引用来自“南湖船老大”的评论 https://zb.oschina.net/ 意思就是 发钱, 让别人写###### 做一顿饭,如果你只是让人告诉你菜怎么做,饭怎么煮的话,应该会有很多人乐意教你 如果你要别人做一顿饭给你吃,这叫下馆子,要给钱的!!! ######回复 @innocence• : 楼下已经有报价,私信他们咯######多少钱,我给就是了。你给我写出来就行######500排队######200带走···######60带走######50不能再低了!######这个页要问别人要钱,开源中国 都些这样的人?######回复 @maradona : 你特么在逗我笑了呢 这一看就知道是学生来提问 或者初学者 还特么售后,你已经钻到钱眼里去了吧######给钱都不愿意干啊,看起来很简单,但完全没赚头,再小也是个J2EE工程啊,数据库web容器缺一不可,还有售后,你要帮人家搭建好环境,甚至java,maven,数据库都要替他搞定,最怕的是还得让他知道怎么跑项目,给他答疑(这么简单都不会做,估计会的真不多,基本是新手状态了),费的时间精力完全跟报酬不成正比,除非他是土豪,花个1000+以上哥就干###### 引用来自“茕鹰”的评论这个页要问别人要钱,开源中国 都些这样的人? 我还是比较克制的描述下我的观点,1.我这人对钱真没那么在意,在意的是时间,他用钱买我的时间这也是很正常,做这个对我一点都没提高,他又不是妹子,跟他交流完全不会提高我的愉悦感, 2.人家是学生,学生就应该一步一步自己把这个做出来,他明显是让人帮他全做了,所以这已经是生意了,又不是讨论,楼上我已经描述了我的观点,教你做菜是爱好,是互相帮助,给你做菜,那是工作,是劳动成果,那就是钱,当然给钱我都懒得干,说要钱也是调侃罢了,谁真会去要这个钱?只是想让他知难而退罢了 当然言辞有点不当请见谅 ######回复 @innocence• : 就事论事,你这问题提的,哥是半点都没看出来是想请教大家如何解决问题的,而是想找个人替你把这个功能实现罢了. 你去看看别人的帖子,有几个会这么回复?搞得你还虚心请教了...通篇就是一个需求点描述嘛,一个请,谢谢等敬语都没(当然大家不在意这个),也没说自己菜鸟,啥都不会,帮忙指点一下的词语,综上所述,恕我只能把你归类于伸手党######给你1W你不干?我只是想问问该怎么做,果然思想就是不一样,我就不信你们刚开始学得时候没有一大堆问题。这么简单的东西能让你们想这么多,以后你的朋友让你帮他看看你也要钱,也说耽误时间。我只是个初学者,没想到开源中国的人,问一问知识都要钱一样,这个小东西,也不难,可我就是不会,我当然要通过各种渠道弄会,并不是坐享其成,我更不相信你遇到不会的你不去问别人。除非你是神童以后去思考人,换位一下。谢谢请谅解。

kun坤 2020-06-09 15:46:23 0 浏览量 回答数 0

问题

学长学姐见过哪些面试难题,是如何应对的?

琛琛轴子 2020-09-06 23:25:03 6 浏览量 回答数 0

回答

转自:思否 话说当下技术圈的朋友,一起聚个会聊个天,如果不会点大数据的知识,感觉都融入不了圈子,为了以后聚会时让你有聊有料,接下来就跟随我的讲述,一起与大数据混个脸熟吧,不过在“撩”大数据之前,还是先揭秘一下研发这些年我们都经历了啥? 缘起:应用系统架构的从 0 到 1 揭秘:研发这些年我们都经历了啥? 大道至简。生活在技术圈里,大家静下来想想,无论一个应用系统多庞大、多复杂,无非也就是由一个漂亮的网站门面 + 一个丑陋的管理模块 + 一个闷头干活的定时任务三大板块组成。 我们负责的应用系统当然也不例外,起初设计的时候三大模块绑在一起(All in one),线上跑一个 Tomcat 轻松就搞定,可谓是像极了一个大泥球。 衍化至繁。由于网站模块、管理平台、定时任务三大模块绑定在一起,开发协作会比较麻烦,时不时会有代码合并冲突出现;线上应用升级时,也会导致其它模块暂时不能使用,例如如果修改了一个定时任务的配置,可能会导致网站、管理平台的服务暂时不能用。面对诸多的不便,就不得不对 All in one 的大泥球系统进行拆解。 随着产品需求的快速迭代,网站 WEB 功能逐渐增多,我们起初设计时雄心勃勃(All in one 的单体架构),以为直接按模块设计叠加实现就好了,谁成想系统越发显得臃肿(想想也是走弯路啦!)。所以不得不改变实现思路,让模块服务下沉,分布式思想若现——让原来网站 WEB 一个系统做的事,变成由子系统分担去完成。 应用架构的演变,服务模块化拆分,随之而来的就是业务日志、业务数据散落在各处。随着业务的推广,业务量逐日增多,沉淀的数据日益庞大,在业务层面、运维层面上的很多问题,逐渐开始暴露。 在业务层面上,面对监管机构的监管,整合提取散落在各地的海量数据稍显困难;海量数据散落,想做个统计分析报表也非常不易。在运维层面上,由于缺少统一的日志归档,想基于日志做快速分析也比较困难;如果想从散落在各模块的日志中,进行调用链路的分析也是相当费劲。 面对上述问题,此时一个硕大的红色问号出现在我们面前,到底该如何解决? 面对结构化的业务数据,不妨先考虑采用国内比较成熟的开源数据库中间件 Sharding-JDBC、MyCat 看是否能够解决业务问题;面对日志数据,可以考虑采用 ELK 等开源组件。如果以上方案或者能尝试的方式都无法帮我们解决,尝试搬出大数据吧。 那到底什么时候需要用大数据呢?大数据到底能帮我们解决什么问题呢?注意,前方高能预警,门外汉“撩”大数据的正确姿势即将开启。 邂逅:一起撬开大数据之门 槽点:门外汉“撩”大数据的正确姿势 与大数据的邂逅,源于两个头痛的问题。第一个问题是海量数据的存储,如何解决?第二个问题是海量数据的计算,如何解决? 面对这两个头痛的问题,不得不提及谷歌的“三驾马车”(分布式文件系统 GFS、MapReduce 和 BigTable),谷歌“三驾马车”的出现,奠定了大数据发展的基石,毫不夸张地说,没有谷歌的“三驾马车”就没有大数据,所以接下来很有必要逐一认识。 大家都知道,谷歌搜索引擎每天要抓取数以亿计的网页,那么抓取的海量数据该怎么存储? 谷歌痛则思变,重磅推出分布式文件系统 GFS。面对谷歌推出的分布式文件系统 GFS 架构,如 PPT 中示意,参与角色着实很简单,主要分为 GFS Master(主服务器)、GFS Chunkserver(块存储服务器)、GFS Client(客户端)。 不过对于首次接触这个的你,可能还是一脸懵 ,大家心莫慌,接下来容我抽象一下。 GFS Master 我们姑且认为是古代的皇上,统筹全局,运筹帷幄。主要负责掌控管理所有文件系统的元数据,包括文件和块的命名空间、从文件到块的映射、每个块所在的节点位置。说白了,就是要维护哪个文件存在哪些文件服务器上的元数据信息,并且定期通过心跳机制与每一个 GFS Chunkserver 通信,向其发送指令并收集其状态。 GFS Chunkserver 可以认为是宰相,因为宰相肚子里面能撑船,能够海纳百川。主要提供数据块的存储服务,以文件的形式存储于 Chunkserver 上。 GFS Client 可以认为是使者,对外提供一套类似传统文件系统的 API 接口,对内主要通过与皇帝通信来获取元数据,然后直接和宰相交互,来进行所有的数据操作。 为了让大家对 GFS 背后的读写流程有更多认识,献上两首歌谣。 到这里,大家应该对分布式文件系统 GFS 不再陌生,以后在饭桌上讨论该话题时,也能与朋友交涉两嗓子啦。 不过这还只是了解了海量数据怎么存储,那如何从海量数据存储中,快速计算出我们想要的结果呢? 面对海量数据的计算,谷歌再次创新,推出了 MapReduce 编程模型及实现。 MapReduce 主要是采取分而治之的思想,通俗地讲,主要是将一个大规模的问题,分成多个小规模的问题,把多个小规模问题解决,然后再合并小规模问题的结果,就能够解决大规模的问题。 也有人说 MapReduce 就像光头强的锯子和锤子,世界上的万事万物都可以先锯几下,然后再锤几下,就能轻松搞定,至于锯子怎么锯,锤子怎么锤,那就是个人的手艺了。 这么解释不免显得枯燥乏味,我们不妨换种方式,走进生活真实感受 MapReduce。 斗地主估计大家都玩过,每次开玩之前,都会统计一副牌的张数到底够不够,最快的步骤莫过于:分几份给大家一起数,最后大家把数累加,算总张数,接着就可以愉快地玩耍啦... ...这不就是分而治之的思想吗?!不得不说架构思想来源于人们的生活! 再举个不太贴切的例子来感受MapReduce 背后的运转流程,估计很多人掰过玉米,每当玉米成熟的季节,地主家就开始忙碌起来。 首先地主将一亩地的玉米分给处于空闲状态的长工来处理;专门负责掰玉米的长工领取任务,开始掰玉米操作(Map 操作),并把掰好的玉米放到在麻袋里(缓冲区),麻袋装不下时,会被装到木桶中(溢写),木桶被划分为蓝色的生玉米木桶、红色的熟玉米木桶(分区),地主通知二当家来“收”属于自己的那部分玉米,二当家收到地主的通知后,就到相应的长工那儿“拿回”属于自己的那部分玉米(Fetch 操作),二当家对收取的玉米进行处理(Reduce 操作),并把处理后的结果放入粮仓。 一个不太贴切的生活体验 + 一张画得不太对的丑图 = 苦涩难懂的技术,也不知道这样解释,你了解了多少?不过如果以后再谈大数据,知道 MapReduce 这个词的存在,那这次的分享就算成功(哈哈)。 MapReduce 解决了海量数据的计算问题,可谓是力作,但谷歌新的业务需求一直在不断出现。众所周知,谷歌要存储爬取的海量网页,由于网页会不断更新,所以要不断地针对同一个 URL 进行爬取,那么就需要能够存储一个 URL 不同时期的多个版本的网页内容。谷歌面临很多诸如此类的业务场景,面对此类头痛的需求,该怎么办? 谷歌重磅打造了一款类似以“URL + contents + time stamp”为 key,以“html 网页内容”为值的存储系统,于是就有了 BigTable 这个键值系统的存在(本文不展开详述)。 至此,两个头痛的问题就算解决了。面对海量数据存储难题,谷歌推出了分布式文件系统 GFS、结构化存储系统 BigTable;面对海量数据的计算难题,谷歌推出了 MapReduce。 不过静下来想想,GFS 也好、MapReduce 也罢,无非都是秉承了大道至简、一人掌权、其它人办事、人多力量大的设计理念。另外画龙画虎难画骨,建议闲暇之余也多些思考:为什么架构要这么设计?架构设计的目标到底是如何体现的? 基于谷歌的“三驾马车”,出现了一大堆开源的轮子,不得不说谷歌的“三驾马车”开启了大数据时代。了解了谷歌的“三驾马车”的设计理念后,再去看这些开源的轮子,应该会比较好上手。 好了,门外汉“撩”大数据就聊到这儿吧,希望通过上文的分享能够了解几个关键词:大道至简、衍化至繁、谷歌三驾马车(GFS、MapReduce、BigTable)、痛则思变、开源轮子。 白头:番外篇 扯淡:不妨换一种态度 本文至此也即将接近尾声,最后是番外篇~ 首先,借用日本剑道学习心诀“守、破、离”,希望我们一起做一个精进的人。 最后,在有限的时间内要多学习,不要停下学习的脚步,在了解和使用已经有的成熟技术之时,更要多思考,开创适合自己工作场景的解决方案。 文章来源:宜信技术学院 & 宜信支付结算团队技术分享第6期-宜信支付结算部支付研发团队高级工程师许赛赛《揭秘:“撩”大数据的正确姿势》 分享者:宜信支付结算部支付研发团队高级工程师许赛赛 原文首发于公号-野指针

茶什i 2020-01-10 15:19:51 0 浏览量 回答数 0

问题

集群部署时的分布式 Session 如何实现?【Java问答学堂】59期

剑曼红尘 2020-07-16 15:14:21 5 浏览量 回答数 1

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 37578 浏览量 回答数 11

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

第一问简单 用队列就行 第二问 队列中间件或者原子锁 但这就不是同时了######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??######你现在希望实现的就是有序嘛,那肯定要用锁才行,比如两个请求A和B同时发出,首先都需要获取锁,如果没获取成功,就等待,强制有序;存取都一样,只要保证了顺序,其他的都好说。######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??######就是并发及队列的应用,这方面的技术都有相应的解决方案,可以去google搜索试试。######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??######高并发问题嘛。队列 + 微秒时间######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??######gearman######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??###### 第一个比较好解决,业务部分不考虑并发和排序,在表中有2个字段,id(对于mysql用自增,对于oracle用sequence),另一个timestamp记录时间,但是要是原子性事务保证。排序的时候用 order by timestamp,id 就可以了。 第二个,在php这玩意下,不提供线程、并发控制和锁、CAS原子量,mysql没有实现sequence等等,所以你这个方案暂时看很难实现(当然手动锁表之类方式也能实现,但实现了也没啥价值 )。 ######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??###### 有很多数据拥有相同的时间标签, 这个时间标签怎么定的?在计算机里有真正的“同时”? 时间搞细点,再做个队列 ######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??###### 另外,“同时”“并列”这些概念是不对的,只要时间片足够小,先后顺序是一定存在的。 即使并发很大,竞争很激烈,但只有一个能够获得锁,所以看起来“同时”的东西,会变成锁机制下的硬性排序。  ######感谢你的回答!追问:1、向淘宝有时间搞秒杀活动,几十万用户同时发出请求,淘宝是怎样选出第一个请求的? 2、还有如果有几十万用户同时登陆一个网站,在PHP网站下,都是访问到LOGIN.PHP这个文件,这时这个LOGIN.PHP文件是什么样的工作状态??

爱吃鱼的程序员 2020-06-03 16:39:55 0 浏览量 回答数 0

回答

关于线程和线程池的学习,我们可以从以下几个方面入手: 第一,什么是线程,线程和进程的区别是什么 第二,线程中的基本概念,线程的生命周期 第三,单线程和多线程 第四,线程池的原理解析 第五,常见的几种线程池的特点以及各自的应用场景 一、 线程,程序执行流的最小执行单位,是行程中的实际运作单位,经常容易和进程这个概念混淆。那么,线程和进程究竟有什么区别呢?首先,进程是一个动态的过程,是一个活动的实体。简单来说,一个应用程序的运行就可以被看做是一个进程,而线程,是运行中的实际的任务执行者。可以说,进程中包含了多个可以同时运行的线程。 二、 线程的生命周期,线程的生命周期可以利用以下的图解来更好的理解: 第一步,是用new Thread()的方法新建一个线程,在线程创建完成之后,线程就进入了就绪(Runnable)状态,此时创建出来的线程进入抢占CPU资源的状态,当线程抢到了CPU的执行权之后,线程就进入了运行状态(Running),当该线程的任务执行完成之后或者是非常态的调用的stop()方法之后,线程就进入了死亡状态。而我们在图解中可以看出,线程还具有一个则色的过程,这是怎么回事呢?当面对以下几种情况的时候,容易造成线程阻塞,第一种,当线程主动调用了sleep()方法时,线程会进入则阻塞状态,除此之外,当线程中主动调用了阻塞时的IO方法时,这个方法有一个返回参数,当参数返回之前,线程也会进入阻塞状态,还有一种情况,当线程进入正在等待某个通知时,会进入阻塞状态。那么,为什么会有阻塞状态出现呢?我们都知道,CPU的资源是十分宝贵的,所以,当线程正在进行某种不确定时长的任务时,Java就会收回CPU的执行权,从而合理应用CPU的资源。我们根据图可以看出,线程在阻塞过程结束之后,会重新进入就绪状态,重新抢夺CPU资源。这时候,我们可能会产生一个疑问,如何跳出阻塞过程呢?又以上几种可能造成线程阻塞的情况来看,都是存在一个时间限制的,当sleep()方法的睡眠时长过去后,线程就自动跳出了阻塞状态,第二种则是在返回了一个参数之后,在获取到了等待的通知时,就自动跳出了线程的阻塞过程 三、 什么是单线程和多线程? 单线程,顾名思义即是只有一条线程在执行任务,这种情况在我们日常的工作学习中很少遇到,所以我们只是简单做一下了解 多线程,创建多条线程同时执行任务,这种方式在我们的日常生活中比较常见。但是,在多线程的使用过程中,还有许多需要我们了解的概念。比如,在理解上并行和并发的区别,以及在实际应用的过程中多线程的安全问题,对此,我们需要进行详细的了解。 并行和并发:在我们看来,都是可以同时执行多种任务,那么,到底他们二者有什么区别呢? 并发,从宏观方面来说,并发就是同时进行多种时间,实际上,这几种时间,并不是同时进行的,而是交替进行的,而由于CPU的运算速度非常的快,会造成我们的一种错觉,就是在同一时间内进行了多种事情 而并发,则是真正意义上的同时进行多种事情。这种只可以在多核CPU的基础下完成。 还有就是多线程的安全问题?为什么会造成多线程的安全问题呢?我们可以想象一下,如果多个线程同时执行一个任务,name意味着他们共享同一种资源,由于线程CPU的资源不一定可以被谁抢占到,这是,第一条线程先抢占到CPU资源,他刚刚进行了第一次操作,而此时第二条线程抢占到了CPU的资源,name,共享资源还来不及发生变化,就同时有两条数据使用了同一条资源,具体请参考多线程买票问题。这个问题我们应该如何解决那?   有造成问题的原因我们可以看出,这个问题主要的矛盾在于,CPU的使用权抢占和资源的共享发生了冲突,解决时,我们只需要让一条线程战歌了CPU的资源时,阻止第二条线程同时抢占CPU的执行权,在代码中,我们只需要在方法中使用同步代码块即可。在这里,同步代码块不多进行赘述,可以自行了解。 四,线程池 又以上介绍我们可以看出,在一个应用程序中,我们需要多次使用线程,也就意味着,我们需要多次创建并销毁线程。而创建并销毁线程的过程势必会消耗内存。而在Java中,内存资源是及其宝贵的,所以,我们就提出了线程池的概念。 线程池:Java中开辟出了一种管理线程的概念,这个概念叫做线程池,从概念以及应用场景中,我们可以看出,线程池的好处,就是可以方便的管理线程,也可以减少内存的消耗。 那么,我们应该如何创建一个线程池那?Java中已经提供了创建线程池的一个类:Executor 而我们创建时,一般使用它的子类:ThreadPoolExecutor. public ThreadPoolExecutor(int corePoolSize,                                int maximumPoolSize,                                long keepAliveTime,                                TimeUnit unit,                                BlockingQueue workQueue,                                ThreadFactory threadFactory,                                RejectedExecutionHandler handler)这是其中最重要的一个构造方法,这个方法决定了创建出来的线程池的各种属性,下面依靠一张图来更好的理解线程池和这几个参数: 又图中,我们可以看出,线程池中的corePoolSize就是线程池中的核心线程数量,这几个核心线程,只是在没有用的时候,也不会被回收,maximumPoolSize就是线程池中可以容纳的最大线程的数量,而keepAliveTime,就是线程池中除了核心线程之外的其他的最长可以保留的时间,因为在线程池中,除了核心线程即使在无任务的情况下也不能被清除,其余的都是有存活时间的,意思就是非核心线程可以保留的最长的空闲时间,而util,就是计算这个时间的一个单位,workQueue,就是等待队列,任务可以储存在任务队列中等待被执行,执行的是FIFIO原则(先进先出)。threadFactory,就是创建线程的线程工厂,最后一个handler,是一种拒绝策略,我们可以在任务满了知乎,拒绝执行某些任务。 线程池的执行流程又是怎样的呢? 有图我们可以看出,任务进来时,首先执行判断,判断核心线程是否处于空闲状态,如果不是,核心线程就先就执行任务,如果核心线程已满,则判断任务队列是否有地方存放该任务,若果有,就将任务保存在任务队列中,等待执行,如果满了,在判断最大可容纳的线程数,如果没有超出这个数量,就开创非核心线程执行任务,如果超出了,就调用handler实现拒绝策略。 handler的拒绝策略: 有四种:第一种AbortPolicy:不执行新任务,直接抛出异常,提示线程池已满              第二种DisCardPolicy:不执行新任务,也不抛出异常              第三种DisCardOldSetPolicy:将消息队列中的第一个任务替换为当前新进来的任务执行              第四种CallerRunsPolicy:直接调用execute来执行当前任务 五,四种常见的线程池: CachedThreadPool:可缓存的线程池,该线程池中没有核心线程,非核心线程的数量为Integer.max_value,就是无限大,当有需要时创建线程来执行任务,没有需要时回收线程,适用于耗时少,任务量大的情况。 SecudleThreadPool:周期性执行任务的线程池,按照某种特定的计划执行线程中的任务,有核心线程,但也有非核心线程,非核心线程的大小也为无限大。适用于执行周期性的任务。 SingleThreadPool:只有一条线程来执行任务,适用于有顺序的任务的应用场景。 FixedThreadPool:定长的线程池,有核心线程,核心线程的即为最大的线程数量,没有非核心线程 作者:weixin_40271838 来源:CSDN 原文:https://blog.csdn.net/weixin_40271838/article/details/79998327 版权声明:本文为博主原创文章,转载请附上博文链接!

auto_answer 2019-12-02 01:56:43 0 浏览量 回答数 0

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

分布式系统 CAP 定理 P 代表什么含义【Java问答学堂】55期

剑曼红尘 2020-07-10 14:49:59 12 浏览量 回答数 1

问题

分布式服务接口的幂等性如何设计(比如不能重复扣款)?【Java问答学堂】52期

剑曼红尘 2020-07-08 09:15:27 3 浏览量 回答数 1

问题

你们有没有做 MySQL 读写分离?如何实现 MySQL 的读写分离?【Java问答】44期

剑曼红尘 2020-06-24 08:34:06 8 浏览量 回答数 1

问题

SAP上云——助力制造业数字化转型

福利达人 2019-12-01 21:09:17 2793 浏览量 回答数 0

问题

程序员的3年之痒改变的不止薪水

小柒2012 2019-12-01 21:08:36 19089 浏览量 回答数 18

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

问题

【精品问答】前端开发必懂之JS技术二百问

茶什i 2019-12-01 22:05:04 146 浏览量 回答数 0

问题

用 Git 来讲讲二叉树最近公共祖先 6月9日 【今日算法】

游客ih62co2qqq5ww 2020-06-09 15:15:00 12 浏览量 回答数 1

问题

【精品问答】python技术1000问(1)

问问小秘 2019-12-01 21:57:48 454222 浏览量 回答数 19

问题

分布式事务了解吗?你们是如何解决分布式事务问题的?【Java问答学堂】58期

剑曼红尘 2020-07-16 15:11:28 5 浏览量 回答数 1

回答

前言 这期我想写很久了,但是因为时间的原因一直拖到了现在,我以为一两天就写完了,结果从构思到整理资料,再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的,所以我肯定不会一本正经的写,我想了好几个切入点,最后决定用一个完整的电商系统作为切入点,带着大家看看,我们需要学些啥,我甚至还收集配套视频和资料,暖男石锤啊,这期是呕心沥血之作,不要白嫖了。 正文 在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你,傻瓜,肤浅。 我们可不能闭门造车,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet,request、response、cookie、session这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。 Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。 前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始讲后端了。 网关层: 互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。 微服务,分布式,负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢? 负载均衡,LVS 我们机器都是IP访问的,那怎么通过我们申请的域名去请求到服务器呢? DNS 大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验? CDN 我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等? zk 这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。 这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开zk这一层,我们继续往下看。 服务层: 这一层有点东西了,算是整个框架的核心,如果你跟我帅丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。 我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,TCP协议,什么三次握手,四次挥手。 还有进程、线程、协程,什么内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而丙丙还做得不够)。 了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。 JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架,设计模式(包括创建型、结构型、行为型),多线程和并发,I/O流,Stream,网络编程你都需要了解。 代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle,提交代码的时候会去写项目版本管理工具Git。 代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,查看进程,查看文件,各种Vim操作等等。 系统的优化很多地方没优化的空间了,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。 这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud。 了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty。 代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。 他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ,因为他自带了分布式事务的解决方案,大数据的场景你又看到了Kafka。 我上面提到过zk,像Dubbo、Kafka等中间件都是用它做注册中心的,所以很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。 此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化,你可能就会去了解容器化的知识,像**Docker,Kubernetes(K8s)**等。 微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。 好啦我们继续沿着图往下看,那再往下是啥呢? 数据层: 数据库可能是整个系统中最值钱的部分了,在我码文字的前一天,刚好发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,没想到还是照进了现实。 这里也提一点点吧,36小时的故障,其实在互联网公司应该是个笑话了吧,权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的,备份,全量备份,增量备份,延迟备份,异地容灾全部都考虑一下应该也不至于这样,一家上市公司还是有点点不应该。 数据库基本的事务隔离级别,索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全,不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是MongoDB、memcache也有各自的应用场景。 Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制…… 他的大容量存储有问题,你可能需要去了解Pika…. 其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。 你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。 数据接触完了,计算引擎Spark你是不是也不能放过…… 搜索引擎: 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。 那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。 这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现,帅丙只是一直在介绍每个层级的技术栈,并没说到具体的一个路线,那是因为我想让大家先有个认知或者说是扫盲吧,我一样用脑图的方式汇总一下吧,如果图片被平台二压了。 资料/学习网站 Tip:本来这一栏有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。 如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。 总结 我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。 你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。 技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。 但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙,一个在互联网苟且偷生的工具人。 创作不易,本期硬核,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见! 本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。 该回答来自:敖丙

剑曼红尘 2020-03-06 11:35:37 0 浏览量 回答数 0

问题

我用四个命令,总结了 Git 的所有套路 6月8日 【今日算法】

游客ih62co2qqq5ww 2020-06-09 15:16:23 67 浏览量 回答数 1

问题

从入门到精通 | 最实用Java学习路线,内含871节Java视频课程 【每周学习】

问问小秘 2020-05-27 10:17:21 12144 浏览量 回答数 4
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站