pianowh

摘要： 1.实际是go运行时自己控制线程数目(线程池)，执行许多的task(goroutine)，防止线程切换的开销，充分利用多核做并行计算 2.在io等需要等待的操作发生的时候go运行时切换task，但是线程不切换继续执行其他task，io完成后挂起的task重新参与调度 3.底层处理io的实现在wind 阅读全文

摘要： 1.不要在线上库作统计。应该在专用的备库上统计，不影响线上业务。（还真有在线上写各种复杂的sql的-_-） 2.可以用大数据方案，如果实时性要求高可以用storm,spark等方案，实时性要求不高hadoop上写hive就行。（当然需要建设大数据平台咯~） 阅读全文

摘要： 1.redis单线程,本身没有真正事务(pipline等方案都不行) 2.可以用lua脚本实现，在lua脚本执行过程中只要redis不挂并且不宕机就可以保证事务 3.lua脚本不应该太复杂，能精简就精简，特别是高并发业务，能放在应用层做的就在应用层做(例如参数检查)，哪怕只是节省几个纳秒在高并发的时 阅读全文

摘要： 1.适用于json嵌套文档和数组的复杂查询业务 2.数据量上亿以后建议业务层也做水平拆分，完全依赖mongodb自己的集群机制可能有性能问题(baidu op的总结) 3.目测写入查询性能不如mysql(即使写入w=0也不如mysql) 4.耗内存严重,ssd效果不明显 5.查询索引很重要(所有db 阅读全文

摘要： 1)mysql各版本一直在优化主从同步 2)5.7是loss less，但不是zero loss，切换的时候还是会丢数据 3)5.7真正做到了并发复制降低主从延时,5.6没有(基于schema级别做到了) 4)pg有全同步复制方式,mysql原生版本没有(只是半同步)。galera,phxsql,a 阅读全文

摘要： 1)大多数数据库都是wal日志先行方案，因此只要日志落地了即使宕机数据也不会丢。 2)大多数数据库些日志是先写缓存，定时或者定次刷到磁盘上，因此这个时候宕机还没有刷到磁盘上的数据就丢了(当然磁盘自己也有缓存). 3)mysql有参数控制刷日志的频率和方案，但是研究下来都会丢数据 innodb_flu 阅读全文

摘要： 1.精准分页问题 1)传统的精准分页(能获取到总页数并且任意跳转页码)在需要符合条件的记录总数目,pg在这个地方是一个大坑,pg的count查询性能不行(目测不如mysql,sqlserver,mongodb,这些当然项目当中全用过).pg官网wiki给了个count estimate(https: 阅读全文