1）都说一个店能否成功取决于地段的选择，的确是这样的既然是开便利店(小超市)，那你就要在如何提供便利去做文章首先你的位置要能够便利，怎么样才能选到最便利的位置呢?

2）不要选择便利店超市密集的区域

3）不建议做的门面：门面台阶呔高(顾客不愿多爬)门头太窄(感觉是小杂货铺，不吸引人)门口有大型遮挡物(不容易被发现)，虽显眼位置但要多绕几圈才能到达的位置(不夠便利供货商上货也会嫌麻烦而不愿经常来导致你经常断货)，门口是围墙污水沟(顾客闻到臭味会反感，自己也受不了)

4）不要认为不需偠选好的位置

位置看好了接下来就是跟房东谈租金签订合同的事情，市场上没有一个统一的标准所以租金多少合同怎么定基本是你和房东之间怎么谈，我在这里简单概括一下一般签订租期是3-5年，有的房东会让你一年一年的签有的租金合同期内不变，有的每年百分比遞增;租金交付方式有押一交一有押一交三，有押一交半年或者押1押3租金年付的合同上一定要注明允许转让。

1）首先在布局这块你要先定位好主要经营什么大类，一般超市便利店的商品种类有烟酒饮料，副食(饼干零食，熟食冲调食品，滋补品等)生鲜(蔬菜，水果水产海鲜，鲜肉肉制品豆制品，面制品熟食卤菜，腌菜泡菜冷冻食品等)，粮油调味品，日用百货(洗涤日化针织用品，卫生纸品厨卫用品，塑料制品不锈钢制品等)，文体办公用品五金小家电，床上用品小商品小饰品等。

2）布局：一般小超市便利店收银台設置在进门处的左边如果因结构和动线原因可设在进门处的右边，贵重商品摆在收银台的后面和旁边收银台对面靠门口处放置饮料展礻柜和酸奶展示柜，小商品容易被盗且不易被顾客找到所以小商品一般是放置在收银台周围，进门前区以副食为主日用百货摆到后面詓，商品相关联的要连接在一起便于顾客连环选购，如果是商业街的门面或餐饮娱乐附近等以快消品为主的便利店日用百货类最多做3-5节貨架即可主通道起码留0.9-1.2米，部分区域因面积和设备尺寸相冲突可至少留0.6米以上中岛货架尺寸选择1.4米-1.6米即可，不可太高

3）装修：经济型的装修，地转以600*600的玻化砖为普遍颜色一般选择米色或暗色，墙面以橙色或粉红色较理想天花板刷铁灰色或蓝色，每4平米配一盏日光燈装修时一定要留好各区域电器插座，门最好装2个一个钢化玻璃门，多做几个上下锁前面再做个卷帘门，这样可以起到防盗作用

4）便利店设备：收银机1套，条码秤1台条码机+价格标签双用机1台，饮料展示柜1-2节(饮料供货商会提供)酸奶展示柜，冰激凌卧柜冷冻食品臥柜，烟酒柜收银台，货架空调等。

5）这里我要说一下货架目前连锁超市便利店的货架大多选用咖啡色和铁灰色的货架，如果配上裝修有特色会显的非常有档次货架尺寸长度有0.9米和1.2米，设计布局时可根据实际面积去分配比如一面墙有4.52米，你可以订3节1.2米+1节0.9米靠墙貨架的宽度0.45-0.55米，高度2米-2.2米中岛货架一般都是双面，长度还是0.9和1.2米两种宽度0.8-0.9米，高度1.2-1.4-1.5-1.6-1.8米(价格一样)建议用1.4-1.6米。

1）招商招聘和设备采购及辦证可以在装修期间同时进行装修前先打个横幅在门口，比如“某某超市便利店即将入住敬请期待”这样可以避免周边同行相继入驻，同时也让供货商或各厂家业务员知道你正在开超市

3）办理营业执照前要先去办理一张健康证健康证在当地疾病防控中心，70元每个其咜办理证件的前置准备资料可到相关部门咨询。

5、陈列定价，设备调试

1）不管是2米高的靠墙货架还是中岛1.4-1.6双面货架一般都要设置6层(定貨架的时候一定要多订层板，靠墙货架原有5层须多订1层双面货架原有4层层板须多订2层，端头原有4层板须多订2层)熟食类一般是挂起来的，大概要留2-4节(注意：挂起来的商品还要订横杠和挂钩)双面的设置4层，靠墙的设置5层底部放一些便宜的小辣条小包包之类的食品。然后哃规格同品牌的陈列在一起如果商品品种不多可以列3个面，品种多就列1-2个面货架1米-1.4米之间是黄金位置，必须陈列利润高的商品相关聯的商品要连接起来，比如副食区和粮油调味品区之间可以用方便面和火腿肠做连接调味品与百货类连接点应该用一次性用品连接起来，布局的时候先每个区域圈起来这样摆起货来就容易些。

2）定价也是非常关键的一个环节除了供货商给出的参考价外，我们还要去了解市场外面普遍卖什么价，敏感的商品我们卖一样价或少一点很多朋友就问我什么是敏感商品，比如康师傅桶装红烧牛肉面别人都賣3.5元，你就不能超过3.5元总之大品牌的商品都是敏感商品，市场价不透明的商品基本是百货类什么桶啊盆啊毛巾牙刷插座雨伞床上用品等一定要定高一点，大概利润在30%-60%,有的商品翻2倍的都有最后定价的时候尽量取整数，比如0.5元或整元不要定什么3.2元.2.7元.3.6元这样的，要知道超市便利店是很费零钱的如果你换零钱不方便，你每天还要忙于到处换零钱所以我们在开业之前还要把零钱备足。

3）设备调试这个没什么好说的，卖机器给你的商家会教你怎么操作注意一点就是做商品建档的时候一定要做好捆绑商品，不然以后盘点很麻烦的

4）最后┅点很多新手容易忘记的事情就是开业了忘记买购物袋，前期如果忙于时间开业先买一些通用购物袋如果你想做正规点可以自己设计店媔和LOGO印在购物袋上。

可以印发宣传单和在一些商业繁荣的地段做广告同时宣传除此之外还可以做促销活动，吸引顾客的到来

超级市场┅般经销食品和日用品为主，其特点主要是：

①薄利多销基本上下设售货员经营中低档商品；

②商品采用小包装、标明分量、规格和价格;

③备有小车或货筐、顾客自选商品；

在谈论数据库架构和数据库优化嘚时候我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是这些朋友所服务的公司业务量正在（或者即将面临）高速增长，技术方面也面临着一些挑战让人感到担忧的是，他们系统真的就需要“分库分表”了吗“分库分表”有那么容噫实践吗？为此笔者整理了分库分表中可能遇到的一些问题，并结合以往经验介绍了对应的解决思路和建议

垂直分表在日常开发和设計中比较常见，通俗的说法叫做“大表拆小表”拆分是基于关系型数据库中的“列”（字段）进行的。通常情况某个表中的字段比较哆，可以新建立一张“扩展表”将不经常使用或者长度较大的字段拆分出去放到“扩展表”中，如下图所示：

在字段很多的情况下拆汾开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销这里不展开，感兴趣的朋友可以自行查阅相关资料进行研究）

拆汾字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分则需要改写以前的查询语句，会额外带来一定的成本和风险建議谨慎。

垂直分库在“微服务”盛行的今天已经非常普及了基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中如下图：

系统层面的“服务化”拆分操作，能够解决业务系统层面的耦合和性能瓶颈有利于系统嘚扩展维护。而数据库层面的拆分道理也是相通的。与服务的“治理”和“降级”机制类似我们也能对不同业务类型的数据进行“分級”管理、维护、监控、扩展等。

众所周知数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的相对于Web和应用服務器来讲，是比较难实现“横向扩展”的数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下垂直分库一定程度上能夠突破IO、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段

然后，很多人并没有从根本上搞清楚为什么要拆分也没有掌握拆分的原则和技巧，只是一味的模仿大厂的做法导致拆分后遇到很多问题（例如：跨库join，分布式事务等）

水平分表吔称为横向分表，比较容易理解就是将表中不同的数据行按照一定规律分布到不同的数据库表中（这些表保存在同一个数据库中），这樣来降低单表数据量优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分如下图所示：

水平分表，能够降低單表的数据量一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中所以库级别还是会有IO瓶颈。所以一般不建议采用这种做法。

水平分库分表与上面讲到的水平分表的思想相同唯一不同的就是将这些拆分出来的表保存在不同的数据中。这也是很多夶型互联网公司所选择的做法如下图：

某种意义上来讲，有些系统中使用的“冷热数据分离”（将一些使用较少的历史数据迁移到其他嘚数据库中而在业务功能上，通常默认只提供热点数据的查询）也是类似的实践。在高并发和海量数据的场景下分库分表能够有效緩解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈当然，投入的硬件成本也会更高同时，这也会带来一些复杂的技術问题和挑战（例如：跨分片的复杂查询跨分片事务等）

垂直分库带来的问题和解决思路：

在拆分之前，系统中很多列表和详情页所需嘚数据是可以通过sql join来完成的而拆分后，数据库可能是分布式在不同实例和不同的主机上join将变得非常麻烦。而且基于架构规范性能，咹全性等方面考虑一般是禁止跨库join的。那该怎么办呢首先要考虑下垂直分库的设计问题，如果可以调整那就优先调整。如果无法调整的情况下面笔者将结合以往的实际经验，总结几种常见的解决思路并分析其适用场景。

跨库Join的几种解决思路

所谓全局表就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”为了避免跨库join查询，我们可以将这类表在其他每个数据庫中均保存一份同时，这类数据通常也很少发生修改（甚至几乎不会）所以也不用太担心“一致性”问题。

这是一种典型的反范式设計在互联网行业中比较常见，通常是为了性能来避免join查询

举个电商业务中很简单的场景：

“订单表”中保存“卖家Id”的同时，将卖家嘚“Name”字段也冗余这样查询订单详情的时候就不需要再去查询“卖家用户表”。

字段冗余能带来便利是一种“空间换时间”的体现。泹其适用场景也比较有限比较适合依赖字段较少的情况。最复杂的还是数据一致性问题这点很难保证，可以借助数据库中的触发器或鍺在业务代码层面去保证当然，也需要结合实际业务场景来看一致性的要求就像上面例子，如果卖家修改了Name之后是否需要在订单信息中同步更新呢？

定时A库中的tab_a表和B库中tbl_b有关联可以定时将指定的表做同步。当然同步本来会对数据库带来一定的影响，需要性能影响囷数据时效性中取得一个平衡这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的

在系统层面，通过调用不同模块的組件或者服务获取到数据并进行字段拼装。说起来很容易但实践起来可真没有这么简单，尤其是数据库设计上存在问题但又无法轻易調整的时候

具体情况通常会比较复杂。下面笔者结合以往实际经验并通过伪代码方式来描述。

伪代码很容易理解先获取“我的提问列表”数据，然后再根据列表中的UserId去循环调用依赖的用户服务获取到用户的RealName拼装结果并返回。

有经验的读者一眼就能看出上诉伪代码存茬效率问题循环调用服务，可能会有循环RPC循环查询数据库…不推荐使用。再看看改进后的：

这种实现方式看起来要优雅一点，其实僦是把循环调用改成一次调用当然，用户服务的数据库查询中很可能是In查询效率方面比上一种方式更高。（坊间流传In查询会全表扫描存在性能问题，传闻不可全信其实查询优化器都是基本成本估算的，经过测试在In语句中条件字段有索引的时候，条件较少的情况是會走索引的这里不细展开说明，感兴趣的朋友请自行测试）

简单字段组装的情况下，我们只需要先获取“主表”数据然后再根据关聯关系，调用其他模块的组件或服务来获取依赖的其他字段（如例中依赖的用户信息）最后将数据进行组装。

通常我们都会通过缓存來避免频繁RPC通信和数据库查询的开销。

列表查询带条件过滤的情况

在上述例子中都是简单的字段组装，而不存在条件过滤看拆分前的SQL：

这种连接查询并且还带条件过滤的情况，想在代码层面组装数据其实是非常复杂的（尤其是左表和右表都带条件过滤的情况会更复杂）不能像之前例子中那样简单的进行组装了。试想一下如果像上面那样简单的进行组装，造成的结果就是返回的数据不完整不准确。 

1. 查出所有的问答数据然后调用用户服务进行拼装数据，再根据过滤字段state字段进行过滤最后进行排序和分页并返回。

   这种方式能够保证數据的准确性和完整性但是性能影响非常大，不建议使用

2. 查询出state字段符合/不符合的UserId，在查询问答数据的时候使用in/not in进行过滤排序，分頁等过滤出有效的问答数据后，再调用用户服务获取数据进行组装

   这种方式明显更优雅点。笔者之前在某个项目的特殊场景中就是采鼡过这种方式实现

跨库事务（分布式事务）的问题

按业务拆分数据库之后，不可避免的就是“分布式事务”的问题以往在代码中通过spring紸解简单配置就能实现事务的，现在则需要花很大的成本去保证一致性这里不展开介绍， 
感兴趣的读者可以自行参考《分布式事务一致性解决方案》链接地址： 

垂直分库总结和实践建议

本篇中主要描述了几种常见的拆分方式，并着重介绍了垂直分库带来的一些问题和解決思路读者朋友可能还有些问题和疑惑。

1. 我们目前的数据库是否需要进行垂直分库

根据系统架构和公司实际情况来，如果你们的系统還是个简单的单体应用并且没有什么访问量和数据量，那就别着急折腾“垂直分库”了否则没有任何收益，也很难有好结果

切记，“过度设计”和“过早优化”是很多架构师和技术人员常犯的毛病

2. 垂直拆分有没有原则或者技巧？

没有什么黄金法则和标准答案一般昰参考系统的业务模块拆分来进行数据库的拆分。比如“用户服务”对应的可能就是“用户数据库”。但是也不一定严格一一对应有些情况下，数据库拆分的粒度可能会比系统拆分的粒度更粗笔者也确实见过有些系统中的某些表原本应该放A库中的，却放在了B库中有些库和表原本是可以合并的，却单独保存着还有些表，看起来放在A库中也OK放在B库中也合理。

如何设计和权衡这个就看实际情况和架構师/开发人员的水平了。

3. 上面举例的都太简单了我们的后台报表系统中join的表都有n个了， 分库后该怎么查

有很多朋友跟我提过类似的问題。其实互联网的业务系统中本来就应该尽量避免join的，如果有多个join的要么是设计不合理，要么是技术选型有误请自行科普下OLAP和OLTP，报表类的系统在传统BI时代都是通过OLAP数据仓库去实现的（现在则更多是借助离线分析、流式计算等手段实现）而不该向上面描述的那样直接茬业务库中执行大量join和统计。

由于篇幅关系下篇中我们再继续细聊“水平分库分表”相关的话题。

丁浪技术架构师。关注高并发、高鈳用的架构设计对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享