标签:arch sea 业务 string size ota 算法 play obj
一:背景1. 讲故事
在开始本文之前,真的好想做个问卷调查,到底有多少人和我一样,对 JsonConvert 的认识只局限在 SerializeObject 和 DeserializeObject 这两个方法上(┬_┬), 这样我也好结伴同行,不再孤单落魄,或许是这两个方法基本上能够解决工作中 80% 的场景,对于我来说确实是这样,但随着编码的延续,终究还是会遇到那剩下的 20% ,所以呀。。。
我的场景是这样的:前段时间写业务代码的时候,我有一个自定义的客户算法类型的Model,这个Model中有这种算法类型下的客户群以及Report统计信息,还用了 HashSet 记录了该类型下的 CustomerID集合,为了方便讲述,我把Model简化如下:
class CustomerAlgorithmModel
{
public string DisplayName { get; set; }
public int CustomerType { get; set; }
public ReprotModel Report { get; set; }
public HashSet<int> CustomerIDHash { get; set; }
}
class ReprotModel
{
public int TotalCustomerCount { get; set; }
public int TotalTradeCount { get; set; }
}
那有意思的就来了,我个人是有记日志的癖好,就想着以后不会出现死无对证的情况,然后就理所当然的使用 JsonConvert.SerializeObject, 这一下就出问题了,日志送入到了 ElasticSearch ,然后通过 Kibana 查不出来,为啥呢?看完上面的 Model 我想你也猜到了原因,json体太大了哈,好歹 CustomerIDHash 中也有几十万个撒,这一下全导出成json了,这 size 还能小吗?要不我写段代码看一看。
static void Main(string[] args)
{
var algorithModel = new CustomerAlgorithmModel()
{
CustomerType = 1,
DisplayName = "
对 JsonConvert 的认识太肤浅了,终于还是遇到了问题
标签:arch sea 业务 string size ota 算法 play obj
原文地址:https://blog.51cto.com/huangxincheng/2525496