一些关于公司和技术的理解
一、elasticsearch（什么值得买）
从极客文化到右脑电商！好文案！
之前并没有听说过这个网站，所以先去了解了一下企业文化和网站内容。网站内容主要是搜罗在各大电商网站的最高性价比商品，以及由使用者们分享的一些原创的关于商品的使用购买经验。而且还有众测板块，众测分为蓝测和红测，可以为消费者提供免费的测试使用商品的机会，且绝大多数是不需要归还商品的。
看到这个网站的时候，只管感觉就是页面没有互联网上的大多数电商平台的界面美观，逻辑结构设计冗余，并不那么舒爽看起来。
我又注意了一下网站的导航栏，分为精选、好价发现、国内、海淘、闲值、好文原创、资讯、好物众测、百科等，分的非常细致非常全面。我想如果对于一个非常有情怀或者说对于一个特别乐于分享购物经历以及商品特性的人来说，这个网站真是妙极了。然而对于一个不喜欢购物，或者说购物的选择条件只是低价、好评、包邮、满减的购物者来说，那么这个网站对于他来说就有些多余了。
原因在于这个网站绝不是以低价或者包邮什么的来推荐商品的，而是以一种右脑思考方式来作为思维主导，右脑思维意味着基于情绪、认同甚至价值观的决策。
从很大程度上来讲，人人都是恋物癖，从这个角度看，整个什么值得买在本质上是无数人在通过文字和图片倾诉自己对某个品牌的情感，到最后，什么值得买的CEO希望建立的是人对于品牌和优质产品的信赖。
与一些比价网站相比，人们购物并不是向机器一样只挑选出价格最低的那个，而是有更多情感的投入，什么值得买则将它进一步扩大化。
我认为：
这个网站的雏形只是CEO的一个个人网站，他们俩是通过一个叫做【Hi PDA】的讨论数码产品的论坛认识的两个人，且两个人都不是技术出身，本着个人的爱好以及夙愿：【我要让世界变成更美好的地方】、【我希望提高大家的生活质量】这个网站出现了。
什么值得买是电商圈里的另类，因为这里是一个让用户说话的地方，将用户的发言以及意见最大化，不过可以从网站内容中看到，网站的每页基本都有可以提意见的地方，由此可见，这个网站确实是另类。我想这也是什么值得买越来越受众的原因之一。
所以如果创业或者说让以后自己的网站更受众，一定要站在用户的角度上，而且不要做无良商家，不要以单纯的牟利为导向，不要追求短暂的盈利，我很喜欢什么值得买CEO的”商业洁癖”，网站页面右侧是网站的广告区域，目前是谷歌提供的随机广告，不在页面主区域放广告是团队公认的原则。
任职资格：
3年PHP开发经验，Elasticsearch,索引结构优化，LINUX，Mysql查询优化和存储优化，restful api接口设计
知识补充：
Elasticsearch
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。
优点：搜索解决方案快，有一个零配置和一个完全免费的搜索模式，简单地使用JSON通过HTTP的索引数据，搜索服务器始终可用，一台开始并扩展到数百，实时搜索，要简单的多租户，建立一个云的解决方案。
小教案：https://www.oschina.net/translate/elasticsearch-getting-started
Restful架构
RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。
（1）每一个URI代表一种资源；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。
RESTful API
网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备……）。
因此，必须有一种统一的机制，方便不同的前端设备与后端进行通信。这导致API构架的流行，甚至出现“API First”的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。
参考：http://www.ruanyifeng.com/blog/2014/05/restful_api.html
二、codeigniter/CI框架（中研网）
三、gulp（找树网）
关于网站的描述:
互联网+时代下的典型产品，【会玩微信就可以免费开店的找树网】。中国风景园林学会以以其专业的眼光、超前的思维，发现 找树网巨大的发展潜力，愿携手共同探索互联网+时代苗木产业电子商务发展的特点与规律，在资源整合、产业升级、职能转型等方面进行积极实践，促进整个行业的信息化发展。
一个关于苗木产业的电子商务网站。
任职资格：
H5+CSS3、JS逻辑、Mysql、php
页面性能优化，熟练使用GULP等代码检查和单元测试工具
我认为：
这家公司对PHP工程师有很大的前端技术要求，可见要自主学习的知识还很多
知识补充：
gulp.js基于流的自动化构建工具
在gulp中运行Mocha测试
““js
var gulp = require(‘gulp’);
var mocha = require(‘gulp-mocha’);
gulp.task(‘default’, function() {
return gulp.src([‘test/test-*.js’], { read: false })
.pipe(mocha({
reporter: ‘spec’,
globals: {
should: require(‘should’)
}
}));
});
““
测试架构mocha
诞生于2011年，是现在最流行的JavaScript测试框架之一，在浏览器和Node环境都可以使用。所谓”测试框架”，就是运行测试的工具。通过它，可以为JavaScript应用添加测试，从而保证代码的质量。除了Mocha以外，类似的测试框架还有Jasmine、Karma、Tape等，也很值得学习。
参考：http://www.ruanyifeng.com/blog/2015/12/a-mocha-tutorial-of-examples.html
四、数据库shard技术(中研网)
我认为
这个应该是个外包公司，技术要求能力很多，给的薪资又少。。。。。。
任职资格
1、能熟练使用PHP+Mysql，并最少具有一年以上PHP项目经验。
2、有CI使用经验，精通者优先；
3、有海量数据建设经验、电商系统开发经验优先；
4、具有MySQL索引优化、查询优化和存储优化经验、PHP缓存技术、静态化设计方面的经验,对服务器端优化开发有思想、曾参与过大访问压力的项目开发者优先,精通mysql数据库设计性能调优、数据库shard设计(数据库分割,表分割,构建数据库集群)者优先。
5、面试请携带书面的简历和可以展示的作品或demo。
知识补充：
sharding
一、基本思想：
Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.
1垂直切分
垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。（这也就是所谓的”share nothing”）。
2水平切分
水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。
3混合切分
让我们从普遍的情况来考虑数据的切分：一方面，一个库的所有表通常不可能由某一张表全部串联起来，这句话暗含的意思是，水平切分几乎都是针对一小搓一小搓（实际上就是垂直切分出来的块）关系紧密的表进行的，而不可能是针对所有表进行的。另一方面，一些负载非常高的系统，即使仅仅只是单个表都无法通过单台数据库主机来承担其负载，这意味着单单是垂直切分也不能完全解决问明。因此多数系统会将垂直切分和水平切分联合使用，先对系统做垂直切分，再针对每一小搓表的情况选择性地做水平切分。从而将整个数据库切分成一个分布式矩阵。
二、切分策略
如前面所提到的，切分是按先垂直切分再水平切分的步骤进行的。垂直切分的结果正好为水平切分做好了铺垫。垂直切分的思路就是分析表间的聚合关系，把关系紧密的表放在一起。多数情况下可能是同一个模块，或者是同一“聚集”。这里的“聚集”正是领域驱动设计里所说的聚集。在垂直切分出的表聚集内，找出“根元素”（这里的“根元素”就是领域驱动设计里的“聚合根”），按“根元素”进行水平切分，也就是从“根元素”开始，把所有和它直接与间接关联的数据放入一个shard里。这样出现跨shard关联的可能性就非常的小。应用程序就不必打断既有的表间关联。比如：对于社交网站，几乎所有数据最终都会关联到某个用户上，基于用户进行切分就是最好的选择。再比如论坛系统，用户和论坛两个模块应该在垂直切分时被分在了两个shard里，对于论坛模块来说，Forum显然是聚合根，因此按Forum进行水平切分，把Forum里所有的帖子和回帖都随Forum放在一个shard里是很自然的。
对于共享数据数据，如果是只读的字典表，每个shard里维护一份应该是一个不错的选择，这样不必打断关联关系。如果是一般数据间的跨节点的关联，就必须打断。
需要特别说明的是：当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。比如：在只考虑垂直切分的时候，被划分到一起的表之间可以保持任意的关联关系，因此你可以按“功能模块”划分表格，但是一旦引入水平切分之后，表间关联关系就会受到很大的制约，通常只能允许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说：当同时进行垂直和水平切分时，在垂直方向上的切分将不再以“功能模块”进行划分，而是需要更加细粒度的垂直切分，而这个粒度与领域驱动设计中的“聚合”概念不谋而合，甚至可以说是完全一致，每个shard的主表正是一个聚合中的聚合根！这样切分下来你会发现数据库分被切分地过于分散了（shard的数量会比较多，但是shard里的表却不多），为了避免管理过多的数据源，充分利用每一个数据库服务器的资源，可以考虑将业务上相近，并且具有相近数据增长速率（主表数据量在同一数量级上）的两个或多个shard放到同一个数据源里，每个shard依然是独立的，它们有各自的主表，并使用各自主表ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的。
1.事务问题：
解决事务问题目前有两种可行的方案：分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。
方案一：使用分布式事务
优点：交由数据库管理，简单有效
缺点：性能代价高，特别是shard越来越多时
方案二：由应用程序和数据库共同控制
原理：将一个跨多个数据库的分布式事务分拆成多个仅处
于单个数据库上面的小事务，并通过应用程序来总控
各个小事务。
优点：性能上有优势
缺点：需要应用程序在事务控制上做灵活设计。如果使用
了spring的事务管理，改动起来会面临一定的困难。
2.跨节点Join的问题
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
3.跨节点的count,order by,group by以及聚合函数问题
这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
参考：http://blog.csdn.net/bluishglc/article/details/6161475/
三、垂直切分粒度问题
垂直切分的粒度指的是在做垂直切分时允许几级的关联表放在一个shard里．这个问题对应用程序和sharding实现有着很大的影响．
关联打断地越多，则受影响的join操作越多，应用程序为此做出的妥协就越大，但单表的路由会越简单，与业务的关联性会越小，就越容易使用统一机制处理．在此方向上的极端方案是：打断所有连接，每张表都配有路由规则，可以使用统一机制或框架自动处理．比如amoeba这样的框架，它的路由能且仅能通过SQL的特征（比如某个表的id）进行路由．
反之，若关联打断地越少，则join操作的受到的限制就小，应用程序需要做出的妥协就越小，但是表的路由就会变复杂，与业务的关联性就越大，就越难使用统一机制处理，需要针对每个数据请求单独实现路由．在此方向上的极端方案是：所有表都在一个shard里，也就是没有垂直切分，这样就没有关联被打断．当然这是非常极端的，除非整个数据库很简单，表的数量很少．
实际的粒度掌控需要结合“业务紧密程度”和“表格数据量”两个因素综合考虑，一般来说：
若划归到一起的表格关系紧密，且数据量并不大，增速也非常缓慢，则适宜放在一个shard里，不需要再进行水平切分;
若划归到一起的表格数据量巨大且增速迅猛，则势必要在垂直切分的基础上再进行水平切分，水平切分就意味着原单一shard会被细分成多个更小的shard，每一个shard存在一个主表（即会以该表ID进行散列的表）和多个相之相关的关联表。
总之，垂直切分的粒度在两个相反的方向上呈现优势与劣势并存并相互博弈的局面．架构师需要做的是结合项目的实际情况在两者之间取得收益最大化的平衡．