yjs2015-03-231234567主要问题有两个：1.首页请求没有缓存，用户过来的请求是动态地址，而首页又比较大，造成很大的流量2.定时刷新的请求，把所有的数据都返回了解决：1.首页开启GZIP2.将定时刷新的请求进行拆分 2015-03-25123456789通过分析日志，查找规律后发现：1.每天有大量无权限的首页请求2.流量异常的请求，有很大一部分是没有权限的请求3.流量从3.20日开

难以管理 脚本多，意味着业务也复杂，交错纵横的数据流都隐藏在脚本中，后期很不好查找定位。 而且脚本程序的代码质量普遍偏低，大多都是流水账式的编程。 另外，编写脚本时没有考虑到后期维护，没有增加一些调试功能，也会导致管理上的问题。 性能问题 脚本往往需要频繁更新数据库，而且脚本中经常为了简化代码，将业务功能通过复杂的sql来实现，这些写入操作会导致数据库堵塞，从而影响前端页面的访问速度。 一个很典型

常见流量问题GZIP压缩未开启 短线宝没有开启GZIP，返回的原始数据很大，开启后减少了80%的数据大小 缓存利用率低 比如短线宝的首页，很多内容针对所有用户都是相同的，但是每个用户来访问，都把整个页面重新返回了，页面html有4000多行，大小150K，这会造成非常多的流量 这种情况，可以动静拆分，对静态数据做好缓存 返回冗余数据 还是短线宝，请求精品内参时，将文章列表和每篇文章的具体数据都返回

场景 有个项目为了安全考虑，采用post方式访问了一个静态html文件，服务器返回405 原因访问静态文件的时候只能使用GET方式，不能使用POST，因此在nginx的返回信息中，在0.6.33版以后就增加了这么一个405错误状态码，意思就是，你不能用POST方式来请求静态文件，错了，要换个别的方法。 解决方案 将405设置为200 在nginx配置中增加：error_page 405 =

注意事项1.该内容仅针对集体户口、单人贷款的情况，非集体户口和夫妻共同贷款会有所差异。 2.建议去之前，先给每个机构打个电话，确认下当天是否可以办理，需要哪些材料，避免到了那边才发现缺少东西。 3.如果是骑电瓶车，建议在每个地点都充充电(我的电瓶车不大好，最后没电了，余杭那边没找到充电的地方，只能推回来，昨天晚上还下大雨) 4.出门前看下天气预报，选个没雨的日子去办理资料 准备工作1.提前一周让人

组员工作安排忙的时候，能够协调人员分担压力(这和专人专职冲突)闲的时候，能够穿插任务避免浪费(这需要你维护一个待完成的需求池) 第一种：以 5 个人的小组为例，包含一个组长+4 个组员，那么可以分为三部分：组长：负责项目方案的设计把关、质量把关，以及搜集和发现团队现存的问题和改进意见，组织讨论，确定具体的改进方案。3 个产品开发人员：负责当前产品需求的实现1 个基础建设人员：和组长一起进行团队改进

简单记住一句话： 客户机生成公钥，追加到服务机 配置很简单：假设客户机为A，服务机为B，现在A想要免密码登录到服务机B1.在A上面生成公钥 ssh-keygen -t rsa 2.将A的公钥追加到B的authorized_keys文件3.检查权限配置完成后，是不需要重启sshd服务的，直接可用 但是可能遇到一个问题，就是配置好了，仍然提示要输入密码这里我理解反了，没有弄清楚其原理 假设有A

接下来因为一些原因，可能需要自己大量阅读代码，这里总结一下之前阅读代码时遇到的问题，以及一些方法。 问题一开始就往代码细节上钻 越是复杂的项目，这样做越是悲剧，你可能花费大量时间从代码上层层往下钻，结果却发现对于整体的功能根本无法掌握，最后迷失在源码中，给自己带来压力。 因为复杂的项目，涉及的业务和逻辑很多，相互之间存在关联关系，仅仅靠代码上去阅读，效率是很低的，而且有些和具体业务结合的代码逻辑，

原理依靠MySQL的fulltext类型索引来实现。 实现生成标签数据入库时进行分词，生成关键字标签；分词方法各语言各异，网上都有开源库，按需使用即可。 查询查询时，先对问句进行分词，然后组装成SQL中的AGAINST参数值，AGAINST的规则如下： +一个领头的加号表示，该词必须出现在每个返回的记录行中。-一个领头的减号表示，该词必须不出现在每个返回的记录行中。 缺省的 (当既没有加号也没有