读书

sjmj 《数据密集型利用零碎设计》 - 数据模型和查询语言概览事实世界的API和相干程序作用于某个特定畛域解决现实生活的某些问题。存储数据的模型能够使JSON也能够是XML类型。如何展现以及示意JSON，以及如何操作和解决数据模型使利用开发人员天职工作。越底层的工程师须要思考的内容越多，须要具备过硬的软硬件常识。NOSQL诞生第一局部讲述了NOSQL为什么会主键由关系模型倒退而来。以及介绍了历史长河中已经被尝试的一些模型信息。 NOSQL之所以越来越受欢迎，次要是上面几个特点： 相比关系型数据库更加灵便的存储模式，反对大的数据集和写入吞吐量。对于一些特定查问操作须要NOSQL实现。开源收费的产品更加受到欢送。关系型数据固有的一些毛病，NOSQL更灵便的表现形式。对象关系匹配问题所谓对象和关系的匹配问题指的是在一个看似简略的事实对象中，如果通过关系型数据库往往须要较多的表之间造成关联关系能力残缺展现。 而应用NOSQL数据模型，则能够间接通过一个JSON模型，展现一个对象的多种嵌套关系。 尽管ORM框架某些水平上解决了数据库数据和对象模型的映射问题，然而并不能齐全解决灵活性问题，在NOSQL上不存在灵活性限度。 最终一对多的关系模型因为不匹配呈现了树状构造： 多对一和多对多多对一须要应用惟一ID进行关联，应用惟一ID的益处是一旦创立就不须要更改，自身的无意义特点也决定了不会被轻易扭转的特点。 如果不应用关联，则多对一的展现须要的是屡次关联查问的操作，把一个对象的内容拆分为多个查问搜寻。 所以一个单体对象在最后非常适合应用繁多的关系模型，而在后续得扩大之中发现对象的嵌套应用关系型数据库尽管也能实现，然而带来是臃肿和业务简单的加剧。 显然文档模型在解决关系的层面上更加灵便。 网络模型网络模型是因为 CODASYL 的标准化被提出，最原始的数据库数据库能够看做是不同厂商施行的CODASYL模型。 对于网络模型的历史，能够看看wiki的相干介绍： CODASYL - Wikipedia CODASYL属于层次模型的推广，网络模型的架构之下每个记录可能多个父节点，通过一个节点服务多个纪录，实现一对多和多对一的模型。 关系链路和关系模型的主键以及外键不同，应用的是相似链表指针串联的形式连贯，多对多的关系模型，须要正确的找到“父节点”，能力再反复的数据中找到匹配后果。 网络模型仅仅是作为过后历史背景下解决无限硬件资源搜寻慢的问题解决的，最大的毛病和他的特点一样，就是这个非凡的“父节点”，为了寻找一条关系链路，须要精确找到父节点，显然这种模型是简单并且难以保护的。 CODASYLwiki解释：CODASYL - Wikipedia 关系模型关系模型定义了表和元组（行）的汇合，反对任意的条件搜寻和表中主外键清晰的逻辑构造，迅速取代网络模型从而失去疾速倒退。 尽管关系型数据库的扩大带来的是越来越简单的关系模型，然而关系模型的最大特点是只须要构建一次查问优化器就能够使得所有的应用程序都能够通用。最终查问优化器解决了网络模型链路查找的痛点问题。 文档模型比拟文档模型为了解决关系模型的复杂化诞生，文档模型的关系也就是外键信息被叫做文档援用，能够通过间接链接查问和解析嵌套“关系”，所以这种设计并没有遵循网络模型繁多父节点的特点。 文档模型和关系模型现今的数据和网络结构通常是文档模型和关系模型的联合，文档模型能够聚合多个关系表的内容仅限一次展现，然而如果存在多对多的关系，因为文档模型的自在肯定水平上须要应用程序进行限度和防备，在这一层面上关系模型显然胜任多对多的解决。 针对关系模型的字段扩大通常须要小心谨慎的实现，比方在MYSQL种批改表alter table须要建设新的BTree树并且进行拷贝工作，如果表十分大会十分久的停机工夫。一种解决形式是通过建设新表拷贝旧表的数据导入来实现，能够保障不受影响的状况下实现备份操作。如果须要聚合多个对象的内容，应用文档模型显然更加适合，而应用关系模型则须要保护宏大的多表构造。 查问局限性 文档模型的瓶颈呈现在自身的数据结构上，尤其是JSON或者XML格局，存储和更新文档模型在文档模型较大的时候磁盘IO的开销比拟大，大文档模型的查问效率也会越发效率低下。 对于文档模型的JSON以及XML优化，将在第一局部的第四章节进行更具体的解说。 关系模型和文档模型交融 支流的数据库在文档模型的倒退之后，逐步引入了对文档模型的兼容，比方Postgresql在9.3之后引入了JSON的API以及原生JSON的存储反对，反对文本以及二进制的存储。 而在文档数据库方面同样存在反向联合关系数据模型的特点，比方MongoDB能够主动解析数据库的援用关系转化为文档模型。 目前看来最终将来两者的模型构造是交融而不是一方取代另一方的模式。数据查询语言申明式查问所谓申明式查问指的是只须要数据模型以及制订后果，通过形象转化数据以及数据显示实现这一个指标实现数据模型展现逻辑上的形象。 换句话说申明式的查问只关注整体的标准，不关注具体的实现，然而在SQL中存在诸多限度，所以SQL也存在许多的优化空间，太过自在和不够自在是申明式查问的长处和毛病。 以此为代表的的申明式查问有上面几种构造： SQLWEB标签命令式查问命令式查问的益处是对于业务解决的灵活性十足， 相比于申明式的形象和难以排查，命令式的查问则具备较强的逻辑性和可排查行。 当然命令式查问最大的问题是随着逻辑的简单，命令会越发的难以浏览，如果不加以重构最终就会造成无奈浏览的代码。然而不管怎么说相比拟申明式语言，命令式显然更容易了解一些。 MapReduce 查问MapReduct是一种编程模型，次要作用是在多机器下面晚餐海量数据处理，最后由Google提出。对于这一数据结构的探讨在第十章也有更为具体的探讨。 上面是可供参考的原始论文： [[Mapreduce.pdf]]（Obsidian） [[三大论文中文版.pdf]]（Obsidian） MapReduce 查问是一种介于申明式和命令式之间的一种组件，代码片段能够被解决框架重复调用。 次要的函数分为 map 函数和 reduce 函数。例如，假如 observations 汇合蕴含如下两个文档： 将上面的的SQL进行 Map 和 Reduce 函数操作 SELECT date_trunc (’ month ’, observation_timestamp) AS sum(num_animals) AS total_animalsFRO问 observationsWHERE family= 'Sharks ’ GROUP BY observation_month ;对于这个查问，首先须要编写相干的 map 和 reduce 函数对于实现下面的雷同成果： ...

 国庆假期打算看书的敌人能够扫码 流动阐明：假期完结，即10月8日，小编会分割中奖的小伙伴，大家记得在此之前不要删除朋友圈，以便到时截图确认~~ 大家记得去【图灵教育】公众号参加流动哦！

引言和[[【英语学习】对于鱼身材部位的英文单词学习]]一样的理由，也是看《老人与海》对于时常呈现的船的相干部位的单词比拟含糊，这一节咱们来看看船的单词学习。 有意思的是如果你在google上搜 boat construction ，外面会有对于从木头到船实现的齐全过程的wiki，然而这和预期不符。 换一种思路，既然是船构造，那么搜寻 boat study - 学习划船。这种形式比拟投机取巧，然而很无效。 上面开始上课。 介绍本次学习的教程应用的是这个上面这个链接。外面介绍了对于船的组成，如何开船划船以及如何自救的基础知识，学英语的同时能够扩大你的生存常识，一举多得。 最重要的是，It's Free，真是太棒了。 A FREE Study Guide | BOATERexam.com® 注意事项：这些内容少数以古代的游艇，快艇等生存比拟常见的船进行介绍。一些千奇百怪的船，比方龙舟，巨型游轮，航空母舰这种，曾经超纲了就不介绍了。 介绍： Boating ResourcesWelcome to the BOATERexam.com Boating Safety Resources Library. We made these resources free so that you can learn more about safe and responsible boating practices。 划船资源欢送来到 BOATERexam.com 划船平安资源库。 咱们收费提供这些资源，以便您理解更多对于平安和负责任的划船做法。 船的根底结构简略模式原文如下： https://aceboater.com/en/boating-terminology 咱们先来点简略的，咱们先来看看上面这几个单词，这几个单词的中文含意很有意思： STERN：船尾PORT： 左舷（？？?）BOW：船头STARBOARD：船的右舷。STAR BOARD。能够本人谷歌翻译查一下左舷的含意，也是 port side。切记不要中国人思维 LEFT BORAD，你这么和老外说老外会认为你是不是借鉴了一个单词 Bow of a boat（船头）Refers to the forward part of a pleasure craft.  ...

《数据密集型利用零碎设计》 - 利用零碎概览 引言零碎利用概览是纯理论的局部尽管很简略，然而看完之后发现其实很多时候有一些术语在本人的观点外面是很狭窄的，作者在书中用了更加谨严的解释话语阐述一些软件和零碎设计中常见的问题。 书中提到的一些试验和理论案例都比拟有意思。也因为是第一章，内容通常不会一上来就会很难很干燥，也是比拟有意思的一个章节。 介绍古代利用设计更加趋势单一化和模块化，古代信息系统到数据量极速收缩，换来的是数据简单和各模块多变，利用零碎通常须要蕴含上面的内容。 数据库：存储数据。高速缓存：为简单操作缩小操作代价，比方CPU的高速缓存，硬盘缓存等。索引：建设数据疾速搜寻和过滤。流解决：异步形式与另一个过程通信。批处理：解决大量累积数据。重新认识数据系统在一个数据系统的架构中，咱们通常会判断一个利用零碎的三种个性反对，这三种个性即：可靠性、可扩大，可维护性。 可靠性所谓可靠性不单单指的是零碎能在产生异样的时候能够失常运行，实际上蕴含更多内容： 利用该程序执行用户冀望性能。容忍谬误数据或者不正确的操作。正当到零碎负载和开释性能。权限治理。简略来说这样到可靠性指的是程序上的牢靠和零碎架构上牢靠以及保证数据的安全性。 另外还须要对于一些和可靠性紧密联系并且常见的术语做出更为严格的解释： 容错：所谓容错不是指容许肯定的谬误，而是指在预感的前提下容许某些特定的问题产生。故障和生效：故障是指组件偏离原始设定的状况，零碎存在复原可能，而生效则是指的整个业务零碎瘫痪并且将无奈提供服务。 打消故障很难，然而更多状况下并不是无奈解决问题，而是由解决问题到程序产生问题，也就是BUG上叠加BUG。有一些方法来检测修复零碎自身是否“失常”，在过来Neflix 的 Chaos Monkey，直译过去就是吵闹的猴子，这个组件通过模仿一些常见故障检测零碎问题，尽管比拟小众然而比拟有意思。拓展：对于很多小团队和小我的项目而言 Simian Army 可能没有太多的意义，但 Chaos Monkey 背地的思维值得咱们学习和应用。 Chaos Monkey 中次要蕴含了上面的内容1、Exception Assault （抛出异样攻打）2、Kill Assault （杀过程攻打）3、Latency Assault （提早卡顿攻打）4、Memory Assault （内存溢出攻打）能够看看Simian Army我的项目：Netflix/SimianArmy · GitHub。如果你能拜访slideshare，也能够看看这个slides： RE: invent: Chaos Monkey。硬件故障：硬件故障个别是通过增加备用组件以备不时之需，比方RAID硬盘，锂电池，异步容备等，为了实现可靠性同时保障高可用都必不可少，然而这几年通过软件容错到形式逐步变成新伎俩，比方降级补丁通过轮流下多节点形式，实现不毁坏集群状况下降级。软件谬误：软件谬误更多指的是长期暗藏而不被发现到BUG，尽管谬误到概率比拟小，然而一旦出错将会是非常复杂的排查流程。针对软件可靠性保障是永远将信将疑的不牢靠，哪怕看似“永远”不可能错处的中央也须要做一些监控和进攻措施，这样能够保障问题产生能够第一工夫排查。（这句话很重要）人为失误：越是简单的环节越是容易出错，上线的流程由一个人负责根本只会呈现在一些垃圾公司外面，凡是正规流程公司都有相似严格或者不那么严格的上线过程，然而上线配置却经常是零碎上线运行更新最有可能遇到到人为失误。可靠性的保障意味着开发和经营老本的高下，所以是最为值得关注的事件。 可扩展性如何形容性能可扩展性在书中提到了推特对于 微小扇出构造的解决方案，这种构造的典型体现是某个用户受到海量到关注，之后当被关注用户公布新的内容会扇出微小的申请，以此来反对海量音讯公布的需要。 这种构造显然是典型的海量的单节点公布订阅和播送呈现的业务场景，针对推特中百万粉丝的博主推送和小众主播的推送解决方案是上面两种： 如果是关系型数据库解决方案，是依照关注者关注工夫程序挨个推送新推文。采纳缓存的形式进行推送，推送用户的时候如果依据缓存找到同一指标，则间接取缓存推送，这样就缩小了不少的零碎开销。这两种都存在肯定的问题，第一种是会加剧读负载压力，第二种尽管显著能解决第一种的问题，然而显著存在节约，最终扩大是发现联合两种状况，对于关注人数较少的用户齐全能够应用第一种计划实时更新，然而对于关注量非常宏大的用户则须要第二种形式。 所以能够认为针对扩展性阐明是在不同解决方案之间寻找平衡点。 所谓到平衡点则须要思考上面两个因素： 1. 业务增大须要扩大多少机器维持原有性能。2. 系统资源不变的状况下如何维持性能。 提早和响应工夫差别？差别次要是响应工夫会蕴含一个服务器从申请到返回那一刻所破费的工夫，所以这里须要算上网络开销。而提早体现在解决工作的时候用了多久。这里举个例子：咱们上传文件从上传按钮点击到返回正确后果的那一刻所破费的全副工夫叫做响应工夫，而提早指的是期待上传动作自身花了多久。那么应该如何掂量性能指标，咱们通常会应用均匀响应工夫作为参考，然而均匀响应工夫实际上不能还原性能。 论断是应该通过中位数+响应工夫排序的伎俩判断性能，依照用户的响应工夫按照大小排序进行解决。 这里有另一个案例是亚马逊依据用户购物拜访网站的响应工夫，响应工夫1S和销售额的影响。 对于一个申请的优化，在初期把2-3S实现的工夫升高到1S是十分无效的，然而到1S以内的优化，比方优化99%的称心申请和1%的不称心申请，优化到最初1%的代价要远高于理论的收益，所以这时候须要转化思路而不是在旧办法方死磕。 所以可扩展性的优化指标目标不是为了极致优化，优良的优化是对数回升的过程，达不到这个指标就要思考老本以及是否值得持续进行。 为了察看系统优化，在进行负载测试的时候申请生成端不能是阻塞式而必须是并发形式，否则会存在测试误差。这句话意思是说在任何测试之前须要保障测试和正当并且牢靠的。 负载减少扩大如何应答扩大减少，目前探讨较多的状况为垂直扩大和程度扩大，垂直扩大指的是降级旧系统配置，程度扩大则认为是部署更多的机器分担负载。 少数状况可能认为多台性能个别的机器强过多数几台强劲的机器，实际上如果保障架构足够强劲，只须要几台性能不错的服务器就能够抵掉多台服务器作用的成果，并且程度扩大到肯定水平之后是无限的。 在垂直扩大和程度扩大中又分为有状态节点扩大和无状态节点扩大。 有状态节点更为通常的做法是应用一台高性能服务器利用单机负载服务申请（留神这里的服务仅仅只应用程序服务），当单点服务无奈撑持之后才会思考应用程度扩大的计划。 无状态节点的扩大则更偏向于程度扩大的形式，所以通常须要多个机器或者应用主备备份的形式进行容灾解决。 而将来利用很有可能是面向分布式的架构，古代的分布式编程接口和框架架构在不断完善。 最初一点是针对雷同吞吐量的机器随着业务场景的不同会有齐全不同的架构设计，可扩大的构造通常意味着组件之间的独立和自身的可扩展性，就像是TCP/IP 模型个别。 然而一旦确立业务架构，后续须要调整架构的代价就会越来越高。 可维护性可维护性蕴含可运维，简略性和可演。可运维指的是在日常工作中能够通过经营团队维持零碎稳定性，简略性既是能用最简洁的逻辑实现需要，还须要保障经营人员可能简略应用，也就是功能完善和零碎残缺， 总结这三大个性实际上都指向一个特点：让运维人员更好地保护零碎，因为无论多能够本人化的零碎，最初还是须要运维人员实现保护操作。 另外，为了实现零碎的简略性，不得不引入形象来解决问题，高级语言也是应用形象来覆盖CPU寄存器，汇编代码，零碎调用复杂性等内容。 使用越宏大的零碎越须要形象的思维，在古代的零碎中为此设置了麻利开发模式，测试驱动凋谢模式以及重构，两个凋谢模式从国内环境来看滥用的趋势还算是比拟多的，所以咱们更应该关注重构的利用。 对于重构的细节，都能够在《重构》这本书当中进行理解。 写在最初第一章探讨了可靠性、可扩展性、可维护性的实践概念，同时梳理了以后时代下各个利用零碎所应答的挑战，并且展望未来随着分布式架构的代码成熟和技术欠缺，哪怕是微笑我的项目也有可能玩上分布式，并且可能就会在不久的未来...... 关联零碎减速：阿姆达定律外围：假如程序划分为两局部：不可并行局部和可并行局部。 ...

前言 很久没有写读书笔记了，其实看了很多本书了，然而始终在整顿，明天的笔记是对于《这样读书就够了》这本书的学习笔记，这本书同样是对“学以致用”这四个字的实际，当然这本书的评估褒贬不一，认为好的人感觉能学到不少货色，认为坏的人感觉就是一本“广告”书。 集体看书的时候采取了两方面的思路去对待这本书，发现各有情理，所以这篇笔记偏差于对于集体晋升有帮忙的内容，这本书的确并不适用于所有人，上面咱们就来看一下这到底是一本什么样的书。 举荐水平 3星半，其实原本想打个4星的，然而作者前面一大半啰里八嗦的常识体系，并且在最初又在反复讲拆书和标签法，并且在之前批评胜利学鸡汤打动本人无用，前面又举例了应用搭建集体常识体系走向胜利的销售鸡汤故事，令人不晓得说什么好..... 集体评估 这本书的重点是拆书法和标签法这两个读书和学习办法，这两个办法有肯定的实际价值，比方记录反思和教训这一点非常不错，能够在做集体经验教训等笔记的时候作为反思应用，也能够作为看书遗记的时候补充。 然而从不好的方面来看，作者花了一大半的篇幅来介绍并且“宣扬”本人的这两套“神技”，这里集体心愿读者不要被“鸡汤”灌顶了，其实实际起来就会发现你既没有参考，你也不晓得是否合乎“规范”，简略了解就是你空有一套秘籍招式却没有规范也没有教练反馈，最终就会想着去退出什么“拆书帮”，让业余的人来领导你读书。这样其实违反了读书自身的意义，读书原本就是一个思考的过程，不要一味用严格规范去对待一本书。 说了这么多之后，是不是感觉这本书一无是处了，其实看这本书要的就是这个成果，因为如果跟着作者的介绍一点点看上来你就会发现书中各种“迷药”让你听听冲动，想想打动，过后不动 。真正有价值的货色反而没有显现出来，并且集体总是感觉这本书的作者有点吹牛本人的意思。 内容概要思维导图： 上面是集体的思维导图地址： https://www.mubucm.com/doc/7iaacOVrGXR 明确为什么读书 首先咱们须要理解并且明确为什么读书，在书中通过大量的篇幅介绍对于读书难的问题，介绍了一个叫做“生存余力”的概念，其实依照简略的了解就是你工作了一天之后很难有精力去晋升本人，这是典型的意志力缺失以及意志力有余的体现，另外作者提到了对于读书的不好景象：“听听冲动，想想打动，过后不动”，所以读书无奈内化为本人的货色那么读书是无用的，真的是这样么？其实我更偏差认为读书是一种独立思考，你在独立思考的过程中其实就是在锤炼思维能力，凭借趣味去进行浏览多少会有所播种，所以哪怕看完遗记书中的内容也不要惋惜，因为总有一刻你会回忆起书中的打动。 拆书法的外围体系 对于拆书法集体笔记不能很好的表述，这里最多是简略介绍，书中对于拆书法的三个字母是： RIA，解释如下： R：浏览以及内容拆页 I：解说疏导 A：拆为己用 下面的步骤依照本人的想法拆分是：精彩片段+集体剖析+理论作用这三个步骤，上面来介绍集体的了解： 精彩片段：这些片段通常能立即让你回味，并且越看越有意思的句子。另外只看一遍在过了一小段时间之后仍然能够回顾起来的内容肯定要重点记录。 集体剖析：集体剖析也就是最初的一步学以致用了，将它作用到理论的生存当中才是有成果的。 学习的境界 书中一直提倡学习促成者，并且激励退出拆书帮成为学习促成者，但实际上并不是每个人都适宜教书或者教人，所以能做到从低级读书者到高级读书者的转变就行了，总结来学习的最高境界是疾速排汇+归为己用，只有常识套用到本人的身上常识才算是施展了本人的价值，这里非常举荐各位读者浏览下《奇异的毕生》这本书，这本书会让你对于工夫和集体治理方面有一个全新的意识（尽管这个案例非常的极其和非凡）。 便签法 这部分内容对集体而言的确没有啥价值了，感兴趣的能够看看思维导图而后看下是否适宜本人。 书中内容实际 既然这本书是对于读书办法的方法论探讨，那么咱们就来尝试依照书中的形式进行拆书，当然鉴于集体是看完书之后刚开始应用，可能无奈达到书中作者的高度，然而置信读者应该能从上面的内容的到肯定的启发。 《自控力》的学以致用 > 不肯定非要援用原文，能够依照本人的意思表白书中讲述的内容即可 I： 在自控力当中讲述了对于自控力转变的三个形式：我不要，我想要，我要做。这三个字说起来非常的简略，然而实际上要做到是十分困难的，你想想咱们的先人要看到丰盛丰满的果实的时候，总是会管制不住，哪怕是自制力强的牛人哪怕是是梅西也只是把可口可乐推了推并且点了一杯水，他也只是不看引诱，这和他长年锤炼进去的意志力无关。 A2: 集体的理论利用: 我不要并不能只是单纯的回绝某种引诱，而是要想方法让大脑不能立即承受引诱，我想要实际上最好的形式是提早满足，比方共事给了你甜点，你能够先放在一边等过了几个小时之后再吃，或者立即去网上找一下这个甜点能有多少的卡路里，并且马上记录下笔记，这时候你的留神就被转移了。通过相似的形式，能够把回绝转化为另一件事的动机，这就是 A1: 1. 反思本人在什么时间段对于甜点没有任何抵抗力，什么时候会处于最放松的状态 2. 认真思考本人在哪些时间段总是容易"热量超标"，本人为了抵制付出了多少的致力 3. 是否有记录本人抵制胜利或者失败的时候的情绪，是否常常检查本人或者总是把责任归咎为下一次? ...

《穷查理宝典》读书笔记前言 这本书对集体来说有一点留念价值，不是书自身，而是我利用了ipad 的margin note3这个软件做了一个思维导图，也是第一次做思维导图，留神附件内容比拟大，倡议应用wifi下载节俭流量。 思维导图链接: https://pan.baidu.com/s/1wElJI3TdB-xO_3SbbsAG_g 提取码: 4auu --来自百度网盘超级会员v6的分享 书籍资源地址： 集体比拟爱看实体书，习惯纸张翻过的感觉，所以并不是每一次的读书笔记都会放资源连贯（其实很多时候懒得找pdf或者忘了），这本书在市面上比拟风行的有两个版本，集体看的是“老人头”的版本，也是最常见的版本，另一个版本是收藏版本的红皮书也挺难看的： 珍藏版：链接: https://pan.baidu.com/s/1B1VhguJWPPZe1dXDQeJAIg 提取码: nmib --来自百度网盘超级会员v6的分享（留神集体看的不是这一版） 经典版：链接: https://pan.baidu.com/s/1UPCybo_CBzoO0C-6vxDQpA 提取码: e9wc --来自百度网盘超级会员v6的分享（集体看的这一版） 集体评估 4.5星，其实想给满分5星的，少半颗星是因为实体书切实是有点贵，这是一本具备很高价值的书，本书齐全不会通知你如何发财，怎么样能力胜利，而是通知你很多简略奢侈的智慧和情理，然而时常被人漠视，比方倡议你和尊敬的领导共事，不要出卖你本人都不会买的货色给他人，以及交一个能领导并且激励你而不是吃饭说废话的敌人，书中提到了如何增长本人的智慧 - 一生学习 ，并且激励你学习多学科的内容并且把握独立思维，最初，查理经常说不要做一个铁锤人，因为在铁锤人看来每一个问题都是一个钉子 。 总之，我非常倡议每一个对于生活态度迷茫的人，精读或者细读这本书。 我的查看清单： 上面是集体总结的查看清单，是本人在工作第一年写年终总结的时候想到的，所以对于查理的人格查看清单比拟有共鸣。 1. 责任心，本人的问题本人背锅，不能给本人的领导或者共事添麻烦，遇到问题想尽所有办法解决。 2. 不要不懂装懂，不懂就要想方法，带着问题去思考问题。 3. 做任何事件，重复想三遍，是不是真的懂了。 4. 业务和技术自身同样重要，跳槽拼的是技术，在公司拼的是业务了解和交付能力。 5. 工作肯定要有看得见的工作量，多久工夫实现，能不能实现，实现不了怎么办，当时都要想好。 6. 多看看他人是怎么做的，反思本人为什么做不到。要多看，要多想 7. 把简略的事件做到极致，能力一直做好。 8. 做事之前先学会做人，先做人后做事，平时要重视多学习。 9. 平时多晋升本人，晋升竞争力，放弃一生学习的理念。 10. 接手我的项目的那一刻这一个我的项目就是属于你写的，你要对所有的性能负责，代码就是你写的。 11. 从任何一家公司进来，不须要很强，你只须要比少数人强就能够了。 ...

《HowTomcatWork》笔记总结（一）前言 这一篇是howTomcatWork的书籍笔记内容。上面是依据书中的内容做的一部分集体笔记。 书籍地址：链接：https://pan.baidu.com/s/1jazo... 提取码：lp96 --来自百度网盘超级会员V6的分享集体评估 没啥好说的，tomcat作者写的书，看了下海淘竟然要500多的确吓到了。尽管代码应用的是tomcat5的版本，然而能够根本了解tomcat的外部工作机制。也能够看到作者是如何用一个十多行的肉鸡服务器代码一直降级成为当初的tomcat的模样。 本文是集体依据看书记录的一些笔记，两头逻辑不肯定连贯，因为有些内容过于根底没有记录的价值，所以挑了一些集体关注的点。 一个最简略的Servlet是如何工作的创立Request 对象，并且解析HTTP的申请信息，通过Request对象封装了这些信息的具体细节具体接口： javax.servlet.ServletRequest 或 javax.servlet.http.ServletRequest创立Response对象,封装了客户需须要的真正数据，封装了响应体的相干信息javax.servlet.ServletResponse 或javax.servlet.http.ServletResponseservlet的service 办法，依据此办法对于申请头进行解析，同时创立response将数据回传给客户端tomcat的根本构造 Tomcat把服务器在大体上能够拆分为两局部，一部分叫做容器，另一部分叫做连接器 连接器作用：接管到每一个 HTTP 申请结构一个 ==request== 和 ==response== 对象 容器作用：承受连接器的申请依据service办法进行响应给对应的客户端 Tomcat 4 和 和 5的次要区别 Tomcat 5 反对 Servlet 2.4 和 JSP 2.0 标准，而 Tomcat 4 反对 Servlet 2.3 和 JSP 1.2。比起 Tomcat 4，Tomcat 5 有一些更有效率的默认连接器。Tomcat 5 共享一个后盾解决线程，而 Tomcat 4 的组件都有属于本人的后盾解决线程。因而，就这一点而言，Tomcat 5 耗费较少的资源。Tomcat 5 并不需要一个映射组件(mapper component)用于查找子组件，因而简化了代码。构建一个最简略的web程序构建对象 下方的代码简略浏览即可，无需本人入手试验 HttpServer用于构建一个服务器，同时建设serverSocket套接字期待链接 调用httprequest.parse()办法代码如下： public class HttpServer { /** * 敞开容器的申请门路 */ private static final String SHUTDOWN = "/SHUTDOWN"; /** * 动态资源根门路 */ public static final String WEBROOT = System.getProperty("user.dir") + File.separator + "webroot"; /** * 是否敞开标识 */ private boolean SHUTDOWN_FLAG = false; public static void main(String[] args) { new HttpServer().await(); } /** * 具体的server 办法，期待socket申请 */ public void await() { // 默认为8080端口 int port = 8080; String host = "127.0.0.1"; ServerSocket serverSocket = null; try { // 创立套接字 serverSocket = new ServerSocket(port, 1, InetAddress.getByName("127.0.0.1")); } catch (IOException e) { e.printStackTrace(); System.exit(-1); } while (!SHUTDOWN_FLAG) { try { // 期待套接字 Socket accept = serverSocket.accept(); HttpRequest httpRequest = new HttpRequest(accept.getInputStream()); // 解决申请数据 httpRequest.parse(); // 创立响应对象，解决响应信息 HttpResponse httpResponse = new HttpResponse(accept.getOutputStream()); // 设置动态资源 httpResponse.setRequest(httpRequest); httpResponse.setResource(); // 敞开的套接字 accept.close(); // 判断申请Url是否为 /shutdown SHUTDOWN_FLAG = httpRequest.getUri().equalsIgnoreCase(SHUTDOWN); } catch (IOException e) { e.printStackTrace(); continue; } } }}HttpRequest 以httpserver 的申请inputstream, 解析申请内容，合成申请uri ...