重新认识CAP 定理.

1. 特指 linearizability Consistency
2. CAP根本没有提到延迟(latency),满足CAP可用性的系统可以花任意长的时间来回复一个请求.
3. CAP系统的模型是一个只能读写单个数据的寄存器,事务(transaction)不在这个定理的范围之内
4. 在设计分布式系统的时候,你需要考虑到更多得多的问题。如果太关注CAP就容易导致忽略了其他重要的问题

通过linux top查看jvm的内存

* top 中那些指标是关于内存的
* 为什么 VIRT 有时候会比系统内存还大
* RES 比 配置jvm 的Xmx还大
* top中DATA代表什么

GLIBCXX_USE_CXX11_ABI

代码在centos7环境上编译可以跑.但是其他同事在测试.刚好手头上有一台rehl8的环境是空闲的. 在rehl8上编译是成功的.但是程序运行就会崩溃. 日志里面可以看到 fusionsphere/so/libfc.so: undefined symbol: _ZN16CFusionSphereSDK10InitialSDKEPFviPKczEP23CFusionSphereDebugLevelRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESD_SD_ 可是程序明明是通过编译没有出错,甚至没有泛型这样的rtti. 明显也不是访问错误内存的段错误.