今天为大家讲述密集柜的文件排序和数据管理

今天为大家讲述密集柜的文件排序和数据管理，排序需求其实也是内容运营需求的一种，无论是运营填写的还是自动拉取的内容，永远都会有调整顺序的需求。不同的坑位对应不同的关注度，不同的视觉焦点，浏览路径。运营往往需要通过调整位置或者加些标记来突出某些内容。比如商品列表，可能近期有几个商品比较好卖，就挪到前面，打上标记，从而促成更多的销量。对于排序和打标需求，往往从后台开始就要预留可扩展字段，到前端也要可以方便的调整位置和加标记才行。对应于排序和打标，筛选也是经常用到的。

比如我搜集了一坨数据，又只想挑一部分来展示，这时候往往需要一个可以方便操作的地方，类似帖子加精，评论 置顶等等。商品类的数据筛选需求就更多啦，不过一般可以集成在搜索功能中，作为通用接口提供。但是，运营同学手动填写的数据再进行筛选，那功能就只能业务 侧自己设计了，可以根据需要增加不同的筛选字段供运营同学填写。数据统计需求是很容易失控的一种需求，产品运营最初往往觉得我要个啥的就够用了，过几天可能说能不能统计下这个按钮的点击量，再过几天可能恨不得把所有的操作都埋点，再加上访问路径、购买路径、转化率、蹦失率、页面停留 时间、点击热图、鼠标轨迹。

再给我出个月度季度报表，趋势图等等。这里，对于数据统计需求一定要评审时梳理好，甚至我觉得可以独立于正常的需求，作为单独的数据统计需求整体梳理后提出。当业务量稳步上升时就会伴随着扩容的需求，尤其当访问量骤增的时候，快速扩容就迫在眉睫了。扩容包含很多方面，一些性能方面的问题会在高并发史迅速凸显，比如查询低效，PHP慢速，无静态化 web，并发压力大等等。此时关于性能优化的一切知识都可以派上用场了，静态化、缓存、查询优化、锁表等等。而机器扩容也没那么简单，除了机器内容的复制还有相应服务的批量 启动，定时任务的执行，日志的归集等等。所以，如果评估时预计业务会有爆发性增长（如微信活动），在资金允许的情况下不妨多准备些机器，总比一发布就挂了强。