关系逻辑

参考资料(要是对于本文的理解不够透彻，必须将以下博客认知阅读，方可全面了解LR)： (1). https://zhuanlan.zhihu.com/p/74874291 (2). 逻辑回归与交叉熵 (3). https://www.cnblogs.com/pinard/p/6029432.html (4). https://zhuanlan.zhihu.com/p/76563562 (5). https://www.cnblogs.com/ModifyRong/p/7739955.html 一、逻辑回归介绍 　　逻辑回归（Logistic Regression）是一种广义线性回归。线性回归解决的是回归问题，预测值是实数范围，逻辑回归则相反，解决的是分类问题，预测值是[0,1]范围。所以逻辑回归名为回归，实为分类。接下来让我们用一句话来概括逻辑回归(LR): 逻辑回归假设数据服从伯努利分布，通过极大化似然函数的方法，运用梯度下降来求解参数，来达到将数据二分类的目的。 这句话包含了五点，接下来一一介绍： 逻辑回归的假设 逻辑回归的损失函数 逻辑回归的求解方法 逻辑回归的目的 逻辑回归如何分类 二、逻辑回归的假设 任何的模型都是有自己的假设，在这个假设下模型才是适用的。 逻辑回归的第一个基本假设是假设数据服从伯努利分布。 伯努利分布：是一个离散型概率分布，若成功，则随机变量取值1；若失败

本篇学习Spring Cloud家族中的重要成员：Hystrix。分布式系统中一个服务可能依赖着很多其他服务，在高并发的场景下，如何保证依赖的某些服务如果出了问题不会导致主服务宕机这个问题就会变得异常重要。 针对这个问题直观想到的解决方案就是做依赖隔离。将不同的依赖分配到不同的调用链中，某一条链发生失败不会影响别的链。今天要说的Hystrix就提供了这样的功能。Hystrix的作用就是处理服务依赖，帮助我们做服务治理和服务监控。 那么Hystrix是如何解决依赖隔离呢？从官网上看到这样一段： Hystrix使用命令模式 HystrixCommand (Command)包装依赖调用逻辑，每个命令在单独线程中/信号授权下执行。 可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可.当调用超时时，直接返回或执行fallback逻辑。 为每个依赖提供一个小的线程池（或信号），如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。 依赖调用结果分:成功，失败（抛出异常），超时，线程拒绝，短路。 请求失败(异常，拒绝，超时，短路)时执行fallback(降级)逻辑。 提供熔断器组件,可以自动运行或手动调用,停止当前依赖一段时间(10秒)，熔断器默认错误率阈值为50%,超过将自动运行。 另外在学习之前大家需要注意的是，Hystrix现在已经停止更新

前情提要： 通俗地说逻辑回归【Logistic regression】算法（一） 逻辑回归模型原理介绍 上一篇主要介绍了逻辑回归中，相对理论化的知识，这次主要是对上篇做一点点补充，以及介绍sklearn 逻辑回归模型的参数，以及具体的实战代码。 1.逻辑回归的二分类和多分类 上次介绍的逻辑回归的内容，基本都是基于二分类的。那么有没有办法让逻辑回归实现多分类呢？那肯定是有的，还不止一种。 实际上二元逻辑回归的模型和损失函数很容易推广到多元 逻辑回归。比如总是认为某种类型为正值，其余为0值。 举个例子，要分类为A，B，C三类，那么就可以把A当作正向数据，B和C当作负向数据来处理，这样就可以用二分类的方法解决多分类的问题，这种方法就是最常用的one-vs-rest，简称OvR。而且这种方法也可以方便得推广到其他二分类模型中（当然其他算法可能有更好的多分类办法）。 另一种多元逻辑回归的方法是Many-vs-Many(MvM)，它会选择一部分类别的样本和另一部分类别的样本来做逻辑回归二分类。 听起来很不可思议，但其实确实是能办到的。比如数据有A，B，C三个分类。 我们将A，B作为正向数据，C作为负向数据，训练出一个分模型。再将A，C作为正向数据，B作为负向数据，训练出一个分类模型。最后B，C作为正向数据，C作为负向数据，训练出一个模型。 通过这三个模型就能实现多分类，当然这里只是举个例子

1、前言   在平时工作开发中，大部分开发人员都花费大量的时间在维护其他人员的代码。很难从头开始开发新代码，很多情况下都是以他人成果为基础的，或者新增修改需求，自己写的代码也会被其他开发人员调用，所以写好一份高质量可维护的代码就显得十分重要。 2、什么是可维护代码 可维护代码需要遵循以下几个特点。 1. 可理解性 -其他人可以接手代码并理解它的意图和一般途径。 2. 直观性 -代码中的东西一看就明白，不管其操作过程有多复杂。 3. 可适应性 -代码以一种数据变化不要求完全重写的方法撰写。 4. 可扩展性 -在代码架构上已考虑在未来允许对核心功能进行扩展。 5. 可调试性 -当有地方出错时，代码可以给你足够的信息快速直接找出问题的所在。 3、代码约定   一种让代码变得可维护的简单途径是形成一套JavaScript代码的书写约定。由于JavaScript的可适应性，代码约定对它很重要。以下小节讨论代码约定的概论。 1.可读性   要让代码可维护，首先它必须可读。可读性的大部分内容和代码缩进相关的，代码整齐的缩进能一眼看出代码块是属于那个功能的，很常见的缩进大小为4个空格，现在大部分编辑器也支持一件格式化代码。可读性另一方面是注释，一般来说，有如下一些地方需要进行注释。 函数和方法 -每个方法或注释都应该包含一个注释，用于描述其目的和用于完成任务所可能使用的算法。 大段代码

假如没有redux： 　　我们使用react进行组件化开发，同时我们将state放在每一个组件里面维护，实际上我们将业务逻辑以组件为单元拆分成互相独立得模块，他被拆到组件中了，试想以下，如果我们开发完一个项目了，另外一个人需要熟悉项目，在查看某一个业务逻辑得时候，他可能要查看四五个组件 并深刻理解每个组件得运作原理 以及和其他组件得关系，才能最终理解 当时得开发人员是如何处理这段业务逻辑得，所以这里会出现什么问题呢？即如果我们只是想单纯得理解某一个业务逻辑，我们不希望在这个理解得过程中混入了不必要的东西，比如前面：我们必须理解组件的内部运作机制，显然这是不必要的。 有了redux之后： 　　我们把业务逻辑的state单独拿出来维护，并设计严格的action和reducer来定义业务逻辑的处理流程，这样的话 当另外一个人接手的时候 在处理业务逻辑的时候 其实他只需要关注 redux的业务逻辑就好了，除非遇到 界面改版 他才需要去了解组件，同时将业务逻辑从视图层抽离出来 也有利于分工。 来源： https://www.cnblogs.com/mrzhu/p/11831339.html

磁盘阵列 RAID介绍 一、简介： 磁盘阵列（ Redundant Arrays of Independent Drives，RAID），有“独立磁盘构成的具有冗余能力的阵列”之意。 最初是由加利福尼亚大学伯克利分校在1988年发表的，旨在效能与成本。简单来说，RAID 是利用多块物理硬盘来组成一个虚拟硬盘，并由这些虚拟的硬盘组成一个矩阵的存储系统的一种技术。它的目的很简单却很重要，毕竟关系到数据，保证数据的安全性、提高数据读写的效率。磁盘阵列主要分类三种： 外接式磁盘矩阵列柜、内接式磁盘矩阵列卡、软件模拟仿真。 磁盘阵列是由很多价格较便宜的磁盘，组合成一个容量巨大的磁盘组，利用个别磁盘提供数据所产生加成效果提升整个磁盘系统效能。利用这项技术，将数据切割成许多区段，分别存放在各个硬盘上。 磁盘阵列还能利用同位检查（Parity Check）的观念，在数组中任意一个硬盘故障时，仍可读出数据，在数据重构时，将数据经计算后重新置入新硬盘中。 独立磁盘冗余阵列 是把相同的数据存储在多个硬盘的不同的地方（因此而冗余）的方法。通过把数据放在多个硬盘上，输入输出操作能以平衡的方式交叠，改良性能。因为多个硬盘增加了平均故障间隔时间（MTBF），储存冗余数据也增加了容错。 容量计算： RAID 0： N块盘组成， 逻辑容量为 N 块盘容量之和； RAID 1： 两块盘组成， 逻辑容量为 1 块盘容量

1. 异常和错误 1.1 错误 程序中难免出现错误，而错误分成两种 1.1.1 语法错误 语法错误：这种错误，根本过不了python解释器的语法检测，必须在程序执行前就改正。 #语法错误示范一 if #语法错误示范二 def test: pass #语法错误示范三 print(haha 1.1.2 逻辑错误 #用户输入不完整(比如输入为空)或者输入非法(输入不是数字) num=input(">>: ") int(num) #无法完成计算 res1=1/0 res2=1+'str' 1.2 什么是异常 异常就是程序运行时发生错误的信号，在python中，错误触发的异常如下： 1.3 异常种类 在python中不同的异常可以用不同的类型（python中统一了类与类型，类型即类）去标识，不同的类对象标识不同的异常，一个异常标识一种错误。 1.3.1 异常例子 1.触发IndexError： l=['egon','aa'] l[3] 2.触发KeyError dic={'name':'egon'} dic['age'] 3.触发ValueError s='hello' int(s) 1.3.2 常用异常 AttributeError 试图访问一个对象没有的树形，比如foo.x，但是foo没有属性x IOError 输入/输出异常；基本上是无法打开文件 ImportError

技术架构，是将产品需求转变为技术实现的过程。技术架构解决的问题包括了如何进行纯技术层面的分层、开发框架选择、语言选择（这里以 JAVA 语言为主）、涉及到各自非功能性需求的技术点（安全、性能、大数据）。技术架构是确定组成应用系统实际运行的技术组件、技术组件之间的关系，以及部署到硬件的策略。 技术架构面临最大的挑战是“不确定性”。在技术架构上，很多时候就会面临这种选择。是要选择业界最新的技术？还是选择团队最熟悉的技术？如果选择最新的技术，遇到新技术出了问题怎么解决？如果选择目前熟悉的技术，后续技术演进怎么办？这些都是架构师在做技术架构过程中需要考虑的。 业务在千变万化、技术在层出不穷，没有一套通用的技术架构模式来适用所有的系统。那么，我们如何保证在做技术架构时，能够实现一个稳定、出色的系统。面对这些“不确定性”时的架构设计问题，这里从战略和战术两个层面来提供一些设计原则。战略层提供的是技术架构的方法和思路，属于顶层设计；战术层提供的是技术架构的技术实践方式，更偏向详细设计。 战略层设计原则 战略层的设计原则就是：合适原则、简单原则、演化原则。 1.1 合适原则 技术人员有一种很强的技术情怀，就是在做设计的过程中，很希望挑战新的技术、在项目中采用最新的框架、或者自己重造一个比业界的还要牛的轮子。这样才能够显示出自己的优秀，以至于不让自己显的那么平庸。比如

几个概念的解释 LEO 日志的结尾位置，也是最后写入(append)消息的位置+1。这个位置不代表消费者能看到，仅仅表示单机的日志写入位置，因为要考虑其他副本的写入情况。leader与follower都有此指标。 HW high water mark的简称，对外公开的消费者的非事务消息(即未提交读模式)的位置。这个值的更新过程比较复杂。leader与follower都有此指标。与LEO的区别 参见这里 LSO 事务消息涉及。最后稳定offset。如果是事务消息(即已提交读模式)，这是消费者能看到的最大位置。可以参见《offset range查询》中 查询最新offset 段落。 epoch leader的年代。0.11版本引入这个概念，为了解决0，8版本在broker挂掉的过程中消息可能丢失和错乱的问题。具体可以参见huxi的 Kafka水位(high watermark)与leader epoch的讨论 The high watermark indicated the offset of messages that are fully replicated, while the end-of-log offset might be larger if there are newly appended records to the leader partition which

聊聊clean code 2017年01月19日 作者: 王烨 文章链接 7521字 16分钟阅读 clean code，顾名思义就是整洁的代码，或者说清晰、漂亮的代码，相信大多数工程师都希望自己能写出这样的代码。 也许这是个千人千面的话题，每个工程师都有自己的理解。比如我，从一个天天被骂代码写得烂的人，逐渐学习成长，到现在也能写的出“人模人样”的代码来了。这期间算是积累了一点经验心得，想和大家分享，抛砖引玉。 本文主要针对面向对象编程的clean code来阐述，面向过程代码的思路会比较不同，不在本文的讨论范畴。 代码大部分时候是用来维护的，而不是用来实现功能的 这个原则适用于大部分的工程。我们的代码，一方面是编译好让机器执行，完成功能需求；另一方面，是写给身边的队友和自己看的，需要长期维护，而且大部分项目都不是朝生夕死的短命鬼。 大部分情况下，如果不能写出清晰好看的代码，可能自己一时爽快，后续维护付出的代价和成本将远高于你的想象。 对清晰好看代码的追求精神，比所有的技巧都要重要。 优秀的代码大部分是可以自描述的，好于文档和注释 当你翻看很多开源代码时，会发现注释甚至比我们自己写的项目都少，但是却能看的很舒服。当读完源码时，很多功能设计就都清晰明了了。通过仔细斟酌的方法命名、清晰的流程控制，代码本身就可以拿出来当作文档使用，而且它永远不会过期。 相反