基本思路:sqlite导出sql保存到mysql

读书笔记，《MySQL必知必会》。

消息队列

坑1:自动填充

何为过大：mongodump之前2G，导入后变成15G，大约8倍.
原因：如果mongo版本小于3，则正常，mongo请升级到3.0版本上，目前3.6.7较稳定版

有很多关于ioc优点说明，比如有如下不同的说法：
01,IoC最原初的目的就是充分利用OO的多态性，使得通过配置文件而不是在代码里硬编码（hardcode）的方式来实例化对象和装配对象图，这样就有了为不同的客户场景服务的灵活性（不同的客户通过配置文件使用不同的子类）。IoC本质上和插件化代码的思路很接近举例来说，软件公司只需要维护一套类库，然后通过使用配置文件装配对象图的方式为不同的客户定制不同版本的软件。这些软件可以在功能上、界面上大相径庭，但是区别只在于配置文件
02,ioc的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理，这可以带来很多好处。第一，资源集中管理，实现资源的可配置和易管理。第二，降低了使用资源双方的依赖程度，也就是我们说的耦合度。

mongo报错WiredTiger.wt, connection: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted

快捷手册mongodb

参考博文:数据库05redis常用命令整理

redis启动

简单整理设计模式相关资料。
 第一，虽然网上有很多教程，但大都不得要领，导致设计模式看起来非常复杂，就个人而言，从毕业到现在，反复学习过不下10遍，但由于工作中使用场景有限，不久就又忘记了。所以计划整理出一个适合个人的学习or复习的教程。
 第二，设计模式，本来是渐进的演化，或者基于需求驱动的，而非静态的结构 也就是说应该是原有结构-》遇到xx问题-》演变成xx结构，最终演变成的xx结构，就是常见的设计模式，但实际开发过程中更为在乎的是“遇到xx问题”，将xx结构变成xx结构。所以需要学习时主动补全一些信息，否则虽然学会了绘制关系图，却不明白在应该那种场景下使用。
 第三，设计模式一样是”需求驱动“，出现了问题，解决问题时才会用，而不是为了套用xx而使用。而且如果有完整源代码，并且自己也懂，修改源代码依然是最优方式，设计模式本来是为了处理模块对接（比如跨系统对接，跨平台对接，找不到源代码等），或者是为了对未来的兼容进行的抽象化。而非增加代码复杂度的累赘（不要为了用而用）。

说明

适配器

模板模式

删远端分支报错remote refs do not exist或git: refusing to delete the current branch解决方法

git merge 的撤销

接口调用存在的问题

近期和p2p公司合作进行闲置资金的货币基金购买。
核心功能自然是原有的网上交易核心service层，之前的service层服务的是ctrl层，现在ctrl层变成了第三方接口，而非常规的网页的ctrl层，简单来说就是重写ctrl层，返回json而非网页。

微信公众号，支付宝服务号对接资料现在已经很多了。但当时资料很少的。
微信公众号是前辈开发的，我是进行二次开发。第一代开发主要集中在普通基金净值查询，不需要登录。后来微信提供了oauth2的认证，支持公众号提取到用户的更详细的信息，就可以通过公众号和用户账号建立绑定关系，从而实现用户查询资产，以及通过菜单中的网页链接登录h5形式的app，进行基金交易。

网站相关技术点简单说明