nginx提示地址或端口被占用解决

今天在启动nginx 的时候遇到如下的错误

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] still could not bind()

nginx也没有启动进程

[root@iZ25dgob05vZ /]# ps -ef|grep nginx

root     12150 12079  0 10:20 pts/0    00:00:00 grep nginx

kill也不能停掉进程

[root@iZ25dgob05vZ /]# killall -9 nginx

nginx: 没有进程被杀死

找了N多答案,都是说是端口被占用,但是各种解决方法无效可尝试以下操作:

1、检查80端口被什么程序占用

命令:fuser -n tcp 80

[root@iZ25dgob05vZ /]# fuser -n tcp 80

80/tcp:               7588

删除对应端口

[root@iZ25dgob05vZ /]# kill -9 7588

重新启动nginx

[root@iZ25dgob05vZ /]#  service nginx restart

Stopping nginx:                                         [FAILED]

Starting nginx:                                            [  OK  ]

JVM编码设置说明

今天服务器发现一个问题,部分中文显示正常,部分中文显示乱码。

简单访问一下,发现服务器解析中文参数没有问题,说明tomcat的编码utf-8已配置。

然后一琢磨,认为是源文件出现了编码问题。结果发现本地显示没问题,只有服务器有问题,那这下这个问题就有意思了。

经过排查,发现服务器端端catalina.sh 里少配置了 file.encoding ,导致解析出现乱码。

思考一下,发现还是有些不对, 为什么本地运行没问题,calalina.sh 配置文件中也没有配置编码,结果不乱码,服务器就乱码了呢?

 

满心欢喜的去查看服务器的默认编码,结果是 utf-8。。。

没有证明自己的预期,预期的结论是,tomcat jvm 没有设置编码,则采用系统的默认编码

由于还有很急的事情,日后再来补全这个测试。

sql server 注意事项(三)

今天在改一个bug的时候发现一条语句不兼容sql server的语句,继上两篇sql server注意事项,现补充两点。

1、上图明显看出是sql别名出问题了,原因是sql server update不支持别名,因此在写sql语句的时候要注意,在sql server环境下 update是不可以使用别名的!

2、在sql server环境下,在写查询sql语句的时候 sql之前不允许存在空格,否则会报上图错误。from 附近语法错误。例如错误语句:“ select * from es_goods”,错误语句中select之前有一个小空格,这样是错误的。正确的语句应该是“select * from es_goods”

睡前滴小idea

一.促销模块构成

营销的4P理论即为产品(Product)价格(Price)渠道(Place)促销(Promotion),促销作为营销的重要一环,承担衔接沟通企业和客户之间重要桥梁的作用。促销是电子商务网站吸引客户目光的一把利器,勾起顾客购买欲望,是给予客户心灵重重一击的一枚糖衣炮弹。

下面介绍一下常用的促销方式

(1)   折价促销

价格一直都是电子商务运行的重点,而折价促销也是电商最擅长且使用最多的促销方式。淘宝双十一,京东购物节。如此大规模的促销都是以折价的方式体现的。折价促销操作简单,效果显著。赢得了众多电商的青睐。而客户也喜欢这种直接受益的促销方式,也对他最为敏感幅度较大的折扣可以刺激客户快速消费。而且慢慢衍生出了网上折扣店这一新兴的营销方式。折价促销有很多方式去体现,例如全场两折,特定商品5折,全场2折起,等等。折价促销也有劣势,当恢复原价就无人问津了。所以才出现双十一期间订单量增加,活动过后一段订单量减少

(2)   团购——拼单式促销

团购是回报式促销的一种,他作为一种新兴的电子商务模式通过客户自行组团,专业团购网站,商家组织团购等形式,提升客户与商家的议价能力,并极大程度地进行商品让利,引起客户客户及业内厂商,甚至基本市场的关注而最常见的就是商家组织团购的形式。随着互联网的发展,团购网站在2010年如雨后春笋般的出现,走在电子商务网络够的前沿。

(3)   惠赠式促销

惠赠式也是一种回报式促销形式,包含很多种实现方式,例如买一赠一,买送礼品,买送积分,买送代金券

(4)   搭配销售

搭配销是客户在浏览一件商品时向他推荐其他商品,这件商品可以与其

他商品搭配起来一起销售同时总价格进行相应幅度的降低。配套的商品必须是客户需要的,且互相有一定的联系。搭配销售相对于其他促销方式有很多优点,一有利于扩大产品销量,二是直接降价会损伤产品价值,搭配销售让顾客觉得实惠又不会对价格进行横向比较

(5)   限时限量促销

物以稀为贵,限量促销就利用人们这个心里。

二.设计思路

电子商务王站促销通过维护老客户,吸引新客户,增加网站黏性,提升销售额和增加产品价值,在促进网站的销售和提升活力的同时,形成运营的良性循环。

  1. 业务设计原则

促销的作用体现在以下几方面。

*  吸引注意力:促销通过比较吸引人注意的方式,将产品,服务等信息传递给客户,引起他们注意。

*  说服功能:通过价格服务等方面的促销方式,说服客户消除疑虑,坚定购买。

*  刺激销售:

  1. 模式设计

下面以b2b2c电商平台团购为例,下面附上按照平台,店铺,买家三种身份在团购中不同职能来描述团购整个流程。

进程AND线程的小漫画

进程(process)和线程(thread)是操作系统的基本概念,但是它们比较抽象,不容易掌握。

最近,我读到一篇材料觉得我对进程和线程有一点领悟。

1.

计算机的核心是CPU,它承担了所有的计算任务。它就像一座工厂,时刻在运行。

2.

假定工厂的电力有限,一次只能供给一个车间使用。也就是说,一个车间开工的时候,其他车间都必须停工。背后的含义就是,单个CPU一次只能运行一个任务。

3.

进程就好比工厂的车间,它代表CPU所能处理的单个任务。任一时刻,CPU总是运行一个进程,其他进程处于非运行状态。

4.

一个车间里,可以有很多工人。他们协同完成一个任务。

5.

线程就好比车间里的工人。一个进程可以包括多个线程。

6.

车间的空间是工人们共享的,比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的,每个线程都可以使用这些共享内存。

7.

可是,每间房间的大小不同,有些房间最多只能容纳一个人,比如厕所。里面有人的时候,其他人就不能进去了。这代表一个线程使用某些共享内存时,其他线程必须等它结束,才能使用这一块内存。

8.

一个防止他人进入的简单方法,就是门口加一把锁。先到的人锁上门,后到的人看到上锁,就在门口排队,等锁打开再进去。这就叫“互斥锁”(Mutual exclusion,缩写 Mutex),防止多个线程同时读写某一块内存区域。

9.

还有些房间,可以同时容纳n个人,比如厨房。也就是说,如果人数大于n,多出来的人只能在外面等着。这好比某些内存区域,只能供给固定数目的线程使用。

10.

这时的解决方法,就是在门口挂n把钥匙。进去的人就取一把钥匙,出来时再把钥匙挂回原处。后到的人发现钥匙架空了,就知道必须在门口排队等着了。这种做法叫做“信号量”(Semaphore),用来保证多个线程不会互相冲突。

不难看出,mutex是semaphore的一种特殊情况(n=1时)。也就是说,完全可以用后者替代前者。但是,因为mutex较为简单,且效率高,所以在必须保证资源独占的情况下,还是采用这种设计。

11.

操作系统的设计,因此可以归结为三点:

(1)以多进程形式,允许多个任务同时运行;

(2)以多线程形式,允许单个任务分成不同的部分运行;

(3)提供协调机制,一方面防止进程之间和线程之间产生冲突,另一方面允许进程之间和线程之间共享资源。

浅谈设计模式

冯老师那天跟我提到设计模式,我觉得还应该很有意思吧,我就逛了逛贴吧和社区。下面就听我这个计算机系的女学渣讲述一下我的学习心得吧。

我:什么是设计模式呢?

师兄:设计可以理解为设计方案,模式呢?是解决问题解决多了,除了一套行之有效方案

我:我对于设计模式的理解,给大家举个例子,以我们的电脑为例子吧,他是一个对象不过有点复杂,是由几千个其它对象组成的,包括主板,硬盘,内存,显卡,网卡,CPU。笔记本在制造的时候,制造商搜集所有零件将它们组装起来。当然啦我们也是可以的,我们可以到京东买一些零件来组装电脑,电脑商并不在乎这些零件是怎么生产的,当然他们要知道零件质量过硬,比如苹果公司会把在各个国家生产的零件搜罗到一起,但是他并不在乎他是怎么生产,制造商只会关心如何通过不同的方式将不同的零件组装起来,以便生产出不同型号的电脑。每种型号的电脑都会有他们独特的设计。设计是需要深思熟虑的,以后的生产只需要遵循设计就好啦。这么一说,加入我们是软件厂商,可以用不同组件来创造出不同的软件。我们尝试着用一种面向对象的方式来开发我们的软件,利用OOD原则来让我们的代码更容易管理、重用和扩展。就像你上面提到的那些相同的问题,如果我们预先就有一些良好的设计,那是不是很棒呢?还有个好消息,我们并不需要自己想。这么多年以来,遭遇同样问题的人们早已发现了许多很棒的解决方案,而且把它们标准化过了。我们管这些方案叫设计模式。

设计其实与生活息息相关,如师兄提到的如果迎宾路堵车,我们该如何解决呢?其实这个问题我们程序的高并发一样。

下一期我们来谈谈这个问题,并谈谈基础的设计问题和解决方案。小女不才,还望包涵。

 

 

 

 

关于程序开发的一些小想法 part1

一、由scope(“prototype”)引发

  1. 昨天峰哥说了一个tag上必须加@scope(“prototype”)这样一个注解 。这个注解是将该类以多例的方式注入spring容器,能够解决多线程访问的线程安全问题;原本v52以前我们的action上也有这样的注释——因为Struts是类级别共享资源,所以在多线程访问时同样会有线程安全问题;修改为spring-mvc之后 ,spring-mvc是方法级别共享资源。所以不存在线程安全问题,因此不用加这样的注解。但是@scope(“prototype”)标注的类不应该被@autowired注入到其他类中,否则当有循环依赖的情况发生时,spring容器会无法初始化,抛出BeanCurrentlyInCreationException异常(参考开涛的博客-跟我学spring3  第三章3.2)
  2. 那么什么是循环依赖?

以maven项目为例,a项目依赖b,b项目依赖c,c项目依赖a,形成了一个闭合环就是循环依赖:

依据maven的生命周期,a项目在进行打包或者安装操作时,需要根据依赖先打包或者安装b,b项目在打包或安装时,需要先打包或安装c,c项目在打包或者安装时,需要先打包项目a;此时就会无限的循环下去直至内存溢出。

以上这种循环依赖无解。如果发生这种情况,一定是我们抽象的不对,假如a,b,c三个项目有共有的依赖,为什么不把他们抽象出来一个单独的项目d来由a,b,c共同依赖呢?

以上是使用maven项目构建时的一个小案例,上次峰哥再讲maven的时候我也提及过,我们在使用maven构建项目时可以考虑按功能抽象,也可以考虑按类型(core与模板分离)抽象。

循环依赖在任何具有依赖关系的技术以及体系中都存在。我们知道开发中如果表示类与类的关系时有以下几种表达方式:

泛化 、继承、实现、依赖、关联、聚合、组合

(参考文档http://www.cnblogs.com/olvo/archive/2012/05/03/2481014.html)

比如我们在将对象实例化并注入spring容器中时,会有一些相应的依赖关系。

 因为scope是singleton的 所以这种循环依赖没有报错(会在实例化过程中提供标识,全容器可见:参考开涛博客第三章3.2)假设此时有任意一个被注入的类scope是prototype的,就不会提供这种全容器可见的标识,因此会抛出上述异常。

因此在设计类的时候,也可以抽取公共部分把循环依赖改变成单向的依赖,这样反而更符合逻辑,更符合开发的规范。

我们从上面的描述,可以理解到面向对象编程存在依赖关系时,应尽量避免循环依赖,从类结构、包结构、项目结构都要尽量避免有循环依赖的出现。

在v62的开发时,会引入一个测试代码质量的工具jdepend,这个大家可以作为一个研究院的课题研究jdepend的使用。

二、我的思考

  1. 接口实现类空实现

我们在写一个功能的时候,包括我也经常做一下操作:在orderController中调用orderManager的一个没有的方法,然后直接在接口中直接增加一个方法,导致StoreOrderManager需要增加一个空实现的方法。

先说说这样做的缺点:会给我们的代码增加很多的冗余,我们的代码本身就很臃肿,一个类1500行,可读性差,可维护性差。

在开发过程中,我们要优先遵循最基本的六大开发原则:开闭原则、接口隔离原则(依赖最小接口)、单一职责原则(一个类要有一组相同功能)、依赖倒置原则(依赖于抽象,不依赖具体)、里氏替换原则(具体实现应该可以互相替换而不被依赖者察觉)、迪米特原则(尽少知道)

还有其他各种原则:我整理了一下,认为这两个比较重要:apo(Avoid Premature Optimization避免提前优化)原则、dry(Don’t repeat yourself)原则

从哪些方面来遵守这样的原则呢?

我们首先要抽象一个service层。我发现,我们之前的代码由于各种历史原因,有的校验在controller中进行,并且有的controller中还包含了部分业务逻辑,这样做是不合理的。Controller是一个控制中心,只负责各种功能性代码的调用与执行;而manager中除了操作数据库,还要处理业务,首先就违背了单一职责、接口隔离、迪米特等原则,再深层次的考虑,会使我们的维护变得困难,对我们功能的扩展造成麻烦。

因此我的构想,在未来的6.3 或者7.0版本(过年前后),所有人这个时间都不要提交代码,大约7-10天的一个周期,从包结构上以模块划分、降低包之间的耦合,从类代码上抽象出一个service层,controller中只写调度,service层只写逻辑,dao层只操作数据库—-从各个角度看,这样更合理;以前我工作的公司都是这么做的,从可用性来讲也存在一定的可行性。在重构期间我们遵循上述八条开发原则,将接口拆分成最小单位,实现拆成最小单位,职责拆成最小单位,从结构上来对我们的代码进行整体优化。

  1. 在讲一点开发体会。

1)      关于脑回路:

举个例子,项目经理说,李冰长得好漂亮。

这个时候,郑皓的脑回路是这样的:

李冰—-漂亮—-泡她

我的脑回路

李冰—-漂亮—-范冰冰—-李晨—-有好车—-阿斯顿马丁—-帕加尼—-意大利—-AC米兰—-巴乔……

所以我们一个团队在共同开发的一款产品的时候,会遇到一个问题,项目经理分配的任务有可能没有按照预期的方向进行。所以此时要实时沟通。但是实时沟通的成本太高,所以我们要基于约定来进行开发。约定就包括了流程图,pdm,原型,优秀的开发者还会涉及uml图。

约定好这些之后,才可以进行开发,细节上可以讨论,但是大原则是基本不变的。这有助于提高我们的开发效率。同时文档齐全,交付时连文档一起交付。

开发完成后还要写一个简单的功能说明文档。

失败的案例。

我们所有的软件工程讲的这些工程学的东西,无非是为了更好更快更高质量的生产,那么放入到程序中质量的体现就是代码的复用性以及扩展性(这里还要加上易用性)。

我在设计“装修”功能时,设计的时候,充分的考虑到了可能的扩展,提前预留了一些扩展的字段;现在看来,这种做法是违反我们开发的原则的(避免提前优化)。

在设计的时候为了开发的方便性,暴露了很多内部逻辑给前端人员,这样用起来很困难。

封装可以解决易用的问题。

预告,下次part2将maven多模块项目的真实面目,敬请期待。

悲观锁与乐观锁

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

转自:http://blog.csdn.net/hongchangfirst/article/details/26004335

看了很多,发现这个总结,太贴切。不知道怎么加自己观点了,只能实际运用加观点了。这里直接转载~

eclipse下svn多分支项目切换及合并

Javashop bug同步解决方案

一、核心问题

在我们处理bug的过程中,经常发生以下场景:解决trunk版bug的同时需要解决v6.1.1版本。

这时我们就要手动切换workspace,手动覆盖;这样搞起来很麻烦;

而当定版之后,在trunk中解决了大量的bug,如果一个一个的去tags版中修复,工作量不亚于重新解决一遍bug。

造成这个问题的主要原因是,我们的svn使用的不够熟练,没有把svn的用法完全提现出来。

二、解决方案

(使用eclipse的subversion插件中的 切换以及合并结合)

场景:v6.1.1定版后第三天,trunk版又解决了大量的bug。

首先,我们要把trunk版的代码down下来,并且保证本地版本最新。

 

Step1:在trunk的workspace中 右键javashop项目-team-切换:

 

Step2:在弹出dialog中输入需要切换的分支的url;例如

svn://newsvn.javamall.com.cn/product/javamall/tags/release_6.1.1/javashop

 

Step3:

切换完分支之后,右键team-合并

 

Step4:

图中的选项含义分别是:

1) 从主干合并到分支

2) 从分支合并到主干

3) 将主干上的修改合并到分支(使用collabnet)

4) 合并2个分支到主干

5) 从主干到分支,手工指定不需要合并的修改

6) 从主干到分支,手工指定要合并的修改

选择第一个,会弹出如下窗口:

 

 

点击finish

 

有变化的文件  有冲突的文件都会显示出来。Svn会自动合并能够合并的代码,而由冲突的则需要手动处理。手动处理完成后,提交即可。

关于maven 项目install报错的问题以及解决办法

  • 问题

近日有很多童鞋反映,javashop 6.1及6.0版本执行mvn install时报错,报错信息大致如下:

经过测试发现,在eclipse环境下运行mvn install正常,而shell下使用指令mvn install则会报错;分析后发现是因为eclipse环境能够识别我们的java resourse,而shell或者命令行下无法识别我们的java resource。

  • 标准的maven项目的目录结构是:src/main/java  
  • 标准的maven项目的test目录结构是:src/test/java
  • 标准的maven项目的配置文件路径是:src/main/resources

当我们不使用这种标准的maven项目结构时,在shell下 执行mvn install 就会发生找不到类或者找不到资源的问题。

  • 解决办法
  • 引入build-helper-maven-plugin插件

    <!– 增加更多的Source和Test Source目录插件 –>
    <plugin>
         <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.12</version>
    </plugin>

  •  配置需要添加的资源目录

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/eop</source>
<source>src/base</source>
</sources>
</configuration>
</execution>

<execution>
<id>add-resource</id>
<phase>generate-resources</phase>
<goals>
<goal>add-resource</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>src/base</directory>
<includes>
<include>**/*.xml</include>
<include>**/*.html</include>
<include>**/*.css</include>
</includes>
</resource>
<resource>
<directory>src/eop</directory>
<includes>
<include>**/*.xml</include>
<include>**/*.html</include>
<include>**/*.css</include>
</includes>
</resource>
</resources>
</configuration>
</execution>

</executions>

</plugin>

  • 配置eclipse lifecycle-mapping

<pluginManagement>
<plugins>
<!–This plugin’s configuration is used to store Eclipse m2e settings
only. It has no influence on the Maven build itself. –>
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>
org.codehaus.mojo
</groupId>
<artifactId>
build-helper-maven-plugin
</artifactId>
<versionRange>
[1.12,)
</versionRange>
<goals>
<goal>add-source</goal>
<goal>add-resource</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>

配置完成之后再试试,看看是不是问题已经解决了?

如果您购买了javashop 的61版,我们已经更新了pom.xml文件哦,只需要更新pom文件即可。

  • 另外在mvn install b2b2c 之前  需要先mvn install javashop